From duke at openjdk.java.net  Tue Feb  1 00:09:12 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 1 Feb 2022 00:09:12 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v16]
In-Reply-To: <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@github.com>
 <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
Message-ID: <wFCT69pboMgiJx3_3ce-cdczm-kN5pNXFAjD-k4UwuY=.b17c1b4e-9347-425b-8f73-d070b6f30fdc@github.com>

On Sat, 29 Jan 2022 06:36:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Changes macoss -> macosx in problem list
>>  - Refactors loadlib_aix: Removes redundant c++ class
>
> src/hotspot/os/aix/os_perf_aix.cpp line 495:
> 
>> 493:     char* name     = NEW_C_HEAP_ARRAY(char, IDENTIFIER_LENGTH, mtInternal);
>> 494:     char* exe_name = NEW_C_HEAP_ARRAY(char, PRFNSZ, mtInternal);
>> 495:     char* cmd_line = NEW_C_HEAP_ARRAY(char, PRARGSZ, mtInternal);
> 
> So the contract with SystemProcess is that its ctor arguments need to be C-heap allocated, and releases them itself? ... okay. May be worthwhile to clean up at some point, or at least comment.

Yeah, this was a bit of a gotcha during development (especially since NetworkInterface is different); I agree it's worth documenting.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From iklam at openjdk.java.net  Tue Feb  1 01:00:09 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 1 Feb 2022 01:00:09 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops [v3]
In-Reply-To: <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
 <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
Message-ID: <_7ho-2xCD3tAv6mIdlebA2bbhLupmVY8ofDGV0sIJx8=.4492cdcb-e646-43c0-8ed4-576db5a06797@github.com>

On Mon, 31 Jan 2022 23:57:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
>> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
>> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
>> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
>> 
>> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
>> 
>> Preliminary HelloWorld startup perf. improvement:
>> 
>> instr delta =    -68813432    -49.7140%
>> time  delta =      -14.720 ms -20.3599%
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code cleanup and added a test case

LGTM. The start-up performance improvement is good! Thanks.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7223

From stuefe at openjdk.java.net  Tue Feb  1 08:59:25 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 1 Feb 2022 08:59:25 GMT
Subject: RFR: JDK-8280941: os::print_memory_mappings() prints segment
 preceeding the inclusion range
Message-ID: <ng0_cMM1jmNAp8y68xFB6Fcr41pJfm4QnGQjNSWQ9n4=.d3713589-fd02-41c7-a84d-16f89bac5d93@github.com>

os::print_memory_mappings() is a helpful little routine to print existing memory mappings within a given range. On Linux, it parses proc/<pid>/maps. But it always prints a segment preceding the start address, e.g. here see the first line:


Range [7f92467a3000-7f92467a9000) contains: 7f924679f000-7f92467a3000 rw-p 00000000 00:00 0
7f92467a3000-7f92467a4000 rwxp 00000000 00:00 0
7f92467a4000-7f92467a5000 rw-p 00000000 00:00 0
7f92467a5000-7f92467a6000 rwxp 00000000 00:00 0
7f92467a6000-7f92467a7000 rw-p 00000000 00:00 0
7f92467a7000-7f92467a8000 rwxp 00000000 00:00 0
7f92467a8000-7f92467a9000 rw-p 00000000 00:00 0


and it should also precede the first line with a newline

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

Commit messages:
 - fix off by one, fix newlines

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

PR: https://git.openjdk.java.net/jdk/pull/7289

From tschatzl at openjdk.java.net  Tue Feb  1 09:38:11 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Feb 2022 09:38:11 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops [v3]
In-Reply-To: <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
 <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
Message-ID: <_9AMhEZyAuj7yV5nRpLC2k642WmAywtIiY4p1ZIgXOM=.6d557a3f-5e17-439b-8b55-39d7c67f75bc@github.com>

On Mon, 31 Jan 2022 23:57:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
>> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
>> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
>> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
>> 
>> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
>> 
>> Preliminary HelloWorld startup perf. improvement:
>> 
>> instr delta =    -68813432    -49.7140%
>> time  delta =      -14.720 ms -20.3599%
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code cleanup and added a test case

GC changes look good to me.

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

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7223

From mkariya at openjdk.java.net  Tue Feb  1 12:53:27 2022
From: mkariya at openjdk.java.net (Mitsuru Kariya)
Date: Tue, 1 Feb 2022 12:53:27 GMT
Subject: RFR: 8280928: os::Linux::get_tick_information is inaccurate if the
 guest fields are non-zero
Message-ID: <M-MNDgV-kYltPZLioM8Fev32vyNJcPWYXy1pnWCwmPI=.861af569-49a9-4137-91b1-2bf5ba59766f@github.com>

Removed `guestNiceTicks` from `os::Linux::get_tick_information` because the guest field in `/proc/stat` is already added to the user field in `/proc/stat` inside the linux kernel.

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

Commit messages:
 - 8280928: os::Linux::get_tick_information is inaccurate if the guest fields are non-zero

Changes: https://git.openjdk.java.net/jdk/pull/7303/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7303&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280928
  Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7303/head:pull/7303

PR: https://git.openjdk.java.net/jdk/pull/7303

From stefank at openjdk.java.net  Tue Feb  1 15:46:11 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 1 Feb 2022 15:46:11 GMT
Subject: RFR: JDK-8280941: os::print_memory_mappings() prints segment
 preceeding the inclusion range
In-Reply-To: <ng0_cMM1jmNAp8y68xFB6Fcr41pJfm4QnGQjNSWQ9n4=.d3713589-fd02-41c7-a84d-16f89bac5d93@github.com>
References: <ng0_cMM1jmNAp8y68xFB6Fcr41pJfm4QnGQjNSWQ9n4=.d3713589-fd02-41c7-a84d-16f89bac5d93@github.com>
Message-ID: <DGbpmEYSdIMIcOOmtj0_TltS_rWvOLKAHO_TDJ39Azg=.0ec0928b-365a-4c54-8a2c-2b59425d6469@github.com>

On Mon, 31 Jan 2022 12:47:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> os::print_memory_mappings() is a helpful little routine to print existing memory mappings within a given range. On Linux, it parses proc/<pid>/maps. But it always prints a segment preceding the start address, e.g. here see the first line:
> 
> 
> Range [7f92467a3000-7f92467a9000) contains: 7f924679f000-7f92467a3000 rw-p 00000000 00:00 0
> 7f92467a3000-7f92467a4000 rwxp 00000000 00:00 0
> 7f92467a4000-7f92467a5000 rw-p 00000000 00:00 0
> 7f92467a5000-7f92467a6000 rwxp 00000000 00:00 0
> 7f92467a6000-7f92467a7000 rw-p 00000000 00:00 0
> 7f92467a7000-7f92467a8000 rwxp 00000000 00:00 0
> 7f92467a8000-7f92467a9000 rw-p 00000000 00:00 0
> 
> 
> and it should also precede the first line with a newline

Marked as reviewed by stefank (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7289

From kbarrett at openjdk.java.net  Tue Feb  1 16:27:12 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 1 Feb 2022 16:27:12 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
Message-ID: <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>

On Sat, 29 Jan 2022 14:44:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 136:
>> 
>>> 134:   if (nbits == 64) {
>>> 135:     assert(count <= 1, "must be");
>>> 136:     return bits;
>> 
>> For consistency with the < 64 case, shouldn't this be `return (count == 0) ? 0 : bits;` ?
>
> @kimbarrett - Thanks for the review! Good catch! I believe you are correct,
> but let's wait for @adinn to chime in here.

Returning 0 if count == 0 and bits otherwise is consistent with the old code,
assuming the problematic shift doesn't cause UB data corruption or something
otherwise strange.  It might do the "mathematically correct" thing of shifting
out all the bits (so zeroing the value).  Another possibility is that the
implemented shift amount for N is N mod word-size (some platforms do that, but
I haven't looked up aarch64), which in this case is 64 mod 64, or 0.  I don't
think there are any other non-strange non-UB-data-corruption possibilities.


result is initially 0.
with the old code:
- if count == 0, there are no iterations, and final result is still 0.
- if count == 1, there is one iteration.
  result <<= nbits
    -- if UB corruption, all bets are off
    -- if shifts by 64, result is unchanged (== 0)
    -- if shifts by 64 mod 64 (== 0), result is unchanged (== 0)
  result |= (bits & mask)
    -- result == bits
- if count > 1, for additional iterations
  result <<= nbits
    -- if UB corruption, all bets are off
    -- if shifts by 64, result == 0
    -- if shifts by 64 mod 64 (== 0), result is unchanged (== bits)
  result |= (bits & mask)
    -- result == bits

So with old code, for count > 0, result == bits (or UB corrupted data).

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From minqi at openjdk.java.net  Tue Feb  1 16:35:15 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 1 Feb 2022 16:35:15 GMT
Subject: RFR: JDK-8280941: os::print_memory_mappings() prints segment
 preceeding the inclusion range
In-Reply-To: <ng0_cMM1jmNAp8y68xFB6Fcr41pJfm4QnGQjNSWQ9n4=.d3713589-fd02-41c7-a84d-16f89bac5d93@github.com>
References: <ng0_cMM1jmNAp8y68xFB6Fcr41pJfm4QnGQjNSWQ9n4=.d3713589-fd02-41c7-a84d-16f89bac5d93@github.com>
Message-ID: <bZx1wrSv3JiS6fylbVdHP6bTb7q5bdvdIxojx_yxuK4=.e339efdc-94d4-4a11-824b-a5e291e4a7fa@github.com>

On Mon, 31 Jan 2022 12:47:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> os::print_memory_mappings() is a helpful little routine to print existing memory mappings within a given range. On Linux, it parses proc/<pid>/maps. But it always prints a segment preceding the start address, e.g. here see the first line:
> 
> 
> Range [7f92467a3000-7f92467a9000) contains: 7f924679f000-7f92467a3000 rw-p 00000000 00:00 0
> 7f92467a3000-7f92467a4000 rwxp 00000000 00:00 0
> 7f92467a4000-7f92467a5000 rw-p 00000000 00:00 0
> 7f92467a5000-7f92467a6000 rwxp 00000000 00:00 0
> 7f92467a6000-7f92467a7000 rw-p 00000000 00:00 0
> 7f92467a7000-7f92467a8000 rwxp 00000000 00:00 0
> 7f92467a8000-7f92467a9000 rw-p 00000000 00:00 0
> 
> 
> and it should also precede the first line with a newline

LGTM.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7289

From stuefe at openjdk.java.net  Tue Feb  1 17:22:16 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 1 Feb 2022 17:22:16 GMT
Subject: RFR: JDK-8280941: os::print_memory_mappings() prints segment
 preceeding the inclusion range
In-Reply-To: <DGbpmEYSdIMIcOOmtj0_TltS_rWvOLKAHO_TDJ39Azg=.0ec0928b-365a-4c54-8a2c-2b59425d6469@github.com>
References: <ng0_cMM1jmNAp8y68xFB6Fcr41pJfm4QnGQjNSWQ9n4=.d3713589-fd02-41c7-a84d-16f89bac5d93@github.com>
 <DGbpmEYSdIMIcOOmtj0_TltS_rWvOLKAHO_TDJ39Azg=.0ec0928b-365a-4c54-8a2c-2b59425d6469@github.com>
Message-ID: <iIBaGOoZiN-AM-Ve_UypSIKn9Lr9Br2Z8qZ8_5_IMqE=.af8f9e7a-cef8-44b3-acf1-fddeb188f7ea@github.com>

On Tue, 1 Feb 2022 15:43:25 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> os::print_memory_mappings() is a helpful little routine to print existing memory mappings within a given range. On Linux, it parses proc/<pid>/maps. But it always prints a segment preceding the start address, e.g. here see the first line:
>> 
>> 
>> Range [7f92467a3000-7f92467a9000) contains: 7f924679f000-7f92467a3000 rw-p 00000000 00:00 0
>> 7f92467a3000-7f92467a4000 rwxp 00000000 00:00 0
>> 7f92467a4000-7f92467a5000 rw-p 00000000 00:00 0
>> 7f92467a5000-7f92467a6000 rwxp 00000000 00:00 0
>> 7f92467a6000-7f92467a7000 rw-p 00000000 00:00 0
>> 7f92467a7000-7f92467a8000 rwxp 00000000 00:00 0
>> 7f92467a8000-7f92467a9000 rw-p 00000000 00:00 0
>> 
>> 
>> and it should also precede the first line with a newline
>
> Marked as reviewed by stefank (Reviewer).

Thanks @stefank and @yminqi.

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

PR: https://git.openjdk.java.net/jdk/pull/7289

From stuefe at openjdk.java.net  Tue Feb  1 17:22:16 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 1 Feb 2022 17:22:16 GMT
Subject: Integrated: JDK-8280941: os::print_memory_mappings() prints segment
 preceeding the inclusion range
In-Reply-To: <ng0_cMM1jmNAp8y68xFB6Fcr41pJfm4QnGQjNSWQ9n4=.d3713589-fd02-41c7-a84d-16f89bac5d93@github.com>
References: <ng0_cMM1jmNAp8y68xFB6Fcr41pJfm4QnGQjNSWQ9n4=.d3713589-fd02-41c7-a84d-16f89bac5d93@github.com>
Message-ID: <Av4HCqzI74kaZdSjEnFstbehWbIRAjfqqCvyb3WpoRE=.6f30b3c1-0b59-40cf-9632-19274bda8512@github.com>

On Mon, 31 Jan 2022 12:47:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> os::print_memory_mappings() is a helpful little routine to print existing memory mappings within a given range. On Linux, it parses proc/<pid>/maps. But it always prints a segment preceding the start address, e.g. here see the first line:
> 
> 
> Range [7f92467a3000-7f92467a9000) contains: 7f924679f000-7f92467a3000 rw-p 00000000 00:00 0
> 7f92467a3000-7f92467a4000 rwxp 00000000 00:00 0
> 7f92467a4000-7f92467a5000 rw-p 00000000 00:00 0
> 7f92467a5000-7f92467a6000 rwxp 00000000 00:00 0
> 7f92467a6000-7f92467a7000 rw-p 00000000 00:00 0
> 7f92467a7000-7f92467a8000 rwxp 00000000 00:00 0
> 7f92467a8000-7f92467a9000 rw-p 00000000 00:00 0
> 
> 
> and it should also precede the first line with a newline

This pull request has now been integrated.

Changeset: d1cc5fda
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d1cc5fda8f9fe3480d661985f15c71a8a9a4a7f8
Stats:     9 lines in 1 file changed: 1 ins; 2 del; 6 mod

8280941: os::print_memory_mappings() prints segment preceeding the inclusion range

Reviewed-by: stefank, minqi

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

PR: https://git.openjdk.java.net/jdk/pull/7289

From vlivanov at openjdk.java.net  Tue Feb  1 19:18:25 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 1 Feb 2022 19:18:25 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported
Message-ID: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>

Testing: hs-tier1 - hs-tier6

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

Commit messages:
 - Compiler support of CP entries in error state

Changes: https://git.openjdk.java.net/jdk/pull/7314/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7314&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279822
  Stats: 451 lines in 10 files changed: 361 ins; 48 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7314.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7314/head:pull/7314

PR: https://git.openjdk.java.net/jdk/pull/7314

From ccheung at openjdk.java.net  Tue Feb  1 19:37:17 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 1 Feb 2022 19:37:17 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops [v3]
In-Reply-To: <_7ho-2xCD3tAv6mIdlebA2bbhLupmVY8ofDGV0sIJx8=.4492cdcb-e646-43c0-8ed4-576db5a06797@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
 <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
 <_7ho-2xCD3tAv6mIdlebA2bbhLupmVY8ofDGV0sIJx8=.4492cdcb-e646-43c0-8ed4-576db5a06797@github.com>
Message-ID: <RCYPhKreApMTUOWt6bFmStNO6VKx8jty3A9IR5MZFVc=.94fcdd4b-25a6-4e41-ae66-a5b8faf22d2b@github.com>

On Tue, 1 Feb 2022 00:57:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code cleanup and added a test case
>
> LGTM. The start-up performance improvement is good! Thanks.

@iklam, @tschatzl, @mseledts Thanks for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/7223

From ccheung at openjdk.java.net  Tue Feb  1 19:37:18 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 1 Feb 2022 19:37:18 GMT
Subject: Integrated: 8255495: Support CDS Archived Heap for uncompressed oops
In-Reply-To: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
Message-ID: <hvDZUTfhuIx7cAT1uqhEPImzgUkK_okepQ6mxwMOgPI=.9b7259d0-cdfa-427e-b3a9-2d05908fb075@github.com>

On Wed, 26 Jan 2022 02:48:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
> 
> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
> 
> Preliminary HelloWorld startup perf. improvement:
> 
> instr delta =    -68813432    -49.7140%
> time  delta =      -14.720 ms -20.3599%

This pull request has now been integrated.

Changeset: d95de5c7
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d95de5c7fea4b224d6cd073a6d6921d7108bb7e1
Stats:     374 lines in 14 files changed: 312 ins; 7 del; 55 mod

8255495: Support CDS Archived Heap for uncompressed oops

Reviewed-by: iklam, tschatzl

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

PR: https://git.openjdk.java.net/jdk/pull/7223

From kvn at openjdk.java.net  Tue Feb  1 19:53:14 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 1 Feb 2022 19:53:14 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <8BpyLsZPMXb-tje4J0r43McD6mDpK0mtMY4GuK-Jk14=.f97e0689-bd84-479e-a191-c8e51d885018@github.com>

On Tue, 1 Feb 2022 19:09:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Testing: hs-tier1 - hs-tier6

Looks fine to me but please explain in PR description what you fixed and how.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7314

From vlivanov at openjdk.java.net  Tue Feb  1 20:09:08 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 1 Feb 2022 20:09:08 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <VMvIaHJ4Cso9vU7yCcY132Sl39A1mWAKZVfYOsgtNBo=.fba404ba-fdaf-4209-a526-15b4e48a70dc@github.com>

On Tue, 1 Feb 2022 19:09:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
> 
> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
> 
> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
> 
> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
> 
> Testing: hs-tier1 - hs-tier6

Vladimir, thanks for the review. I updated the description. (I intended to create a draft PR, but erroneously published it.)

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

PR: https://git.openjdk.java.net/jdk/pull/7314

From duke at openjdk.java.net  Tue Feb  1 21:36:58 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 1 Feb 2022 21:36:58 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v16]
In-Reply-To: <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <7hQIiZw8pBnsp8BrgfVAAB60NoGbGyIGjn7uHAgBs0w=.193ce41e-9dd1-41fb-9d80-e107ca53eb23@github.com>
 <yiwwRKE9cBdKxLTAL_i2a8PgbR6LeHgRt5aF3V1a2Ps=.086e1518-460c-45f5-8206-291503b81e42@github.com>
Message-ID: <ojkdO_C32KnPz5oGH416vlYpLg7Tg8nJmLex62oYmcw=.bfb7e570-5adc-4669-9ed7-ffad775c203c@github.com>

On Sat, 29 Jan 2022 06:51:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Changes macoss -> macosx in problem list
>>  - Refactors loadlib_aix: Removes redundant c++ class
>
> src/hotspot/os/aix/os_perf_aix.cpp line 631:
> 
>> 629:                                                            net_stats[i].ibytes,
>> 630:                                                            net_stats[i].obytes,
>> 631:                                                            *network_interfaces);
> 
> When looking at NetworkInterface, I saw that it copies the name into its own resource-area allocated string in the constructor. This is all over the place, SystemProcess assumes C-heap storage, NetworkInterface uses RA... :(
> 
> The problem now is that your ResourceMark above may also destroy the internal string in NetworkInterface when the Stack is unwound beyond this function.
> 
> Side note: this is what I don't like about how hotspot uses RA. Its often not clear which data are RA allocated without looking at the code. In Objective-C (at least how its used on Mac) they had a clear naming convention for methods that returned storage from the AutoReleasePool.
> 
> The problem is also that with ResourceMarks cutting off your data, you may not see the problem until much later. Usually you only see immediate problems if the underlying arena (a chained list of malloced slabs) added a new slab under your ResourceMark, which then gets free'd when the ResourceMark goes out of scope.
> 
> How to fix this:
> 1) revert to NEW_C_HEAP_ARRAY for your records array here, with appropriate cleanup, and remove ResourceMark
> 3) Change NetworkInterface class to use C-heap instead.
> 
> I'd opt for (1) since it avoids discussions about changing shared code. I opened https://bugs.openjdk.java.net/browse/JDK-8280912 to change NetworkInterface, but don't wait for me.

I made the change in (1) as recommended.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From duke at openjdk.java.net  Tue Feb  1 21:36:56 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 1 Feb 2022 21:36:56 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v17]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:

  Addresses issues from review and other sm fixes
  
  - Adds commenting in regards to memory handling by SystemProcess &
  NetworkInterface classes
  - Replaces explicit initialization and copy of structs with memcpy
  and memset as appropriate
  - Renames internal struct definitions in os_perf_aix
  - Other minor fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/08837098..3618a77d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=15-16

  Stats: 108 lines in 2 files changed: 19 ins; 56 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885

From stuefe at openjdk.java.net  Wed Feb  2 09:02:16 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 2 Feb 2022 09:02:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v17]
In-Reply-To: <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>
Message-ID: <KbIKws5G7jt2cpb8X5ao5foDkDHmc4iBB05ge-ArPbA=.e8ca77a2-56d4-4fd5-8ade-278102f38944@github.com>

On Tue, 1 Feb 2022 21:36:56 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses issues from review and other sm fixes
>   
>   - Adds commenting in regards to memory handling by SystemProcess &
>   NetworkInterface classes
>   - Replaces explicit initialization and copy of structs with memcpy
>   and memset as appropriate
>   - Renames internal struct definitions in os_perf_aix
>   - Other minor fixes

Looks good to me now. 

Can you now use JFR/JMC on AIX with this patch or is further work needed?

Thanks for doing this!

Cheers, Thomas

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6885

From mdoerr at openjdk.java.net  Wed Feb  2 09:18:16 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 2 Feb 2022 09:18:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v17]
In-Reply-To: <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <eKXFNkAWECVY8QOMJydWWbye4bldcAjow3mYcbQFPIE=.cec9301c-5183-475b-afcf-d23968d6f557@github.com>
Message-ID: <Nmh1kOvrUKgzzJi8STmXXct8jVFPot1C4IzrGZdwIrw=.a5df2577-e585-439b-bded-09bf91950fc4@github.com>

On Tue, 1 Feb 2022 21:36:56 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses issues from review and other sm fixes
>   
>   - Adds commenting in regards to memory handling by SystemProcess &
>   NetworkInterface classes
>   - Replaces explicit initialization and copy of structs with memcpy
>   and memset as appropriate
>   - Renames internal struct definitions in os_perf_aix
>   - Other minor fixes

Please don't forget src/hotspot/os_cpu/linux_ppc/thread_linux_ppc.cpp update https://github.com/openjdk/jdk/commit/f37bfeadcf036a75defc64ad7f4a9f5596cd7407

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From thomas.stuefe at gmail.com  Wed Feb  2 10:37:58 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 2 Feb 2022 11:37:58 +0100
Subject: Small question about JDK-8253064 and ObjectMonitor allocation
In-Reply-To: <c46874ee-2d6e-81ec-ea86-c88461e89d76@oracle.com>
References: <CAA-vtUx=3=cWGO-EXdVo23Os+c+CeBbbcuL+iA=7_b_W3TH0QQ@mail.gmail.com>
 <236484d3-0638-30d8-72dd-4dd3ce6e134a@oracle.com>
 <CAA-vtUwEgm4te2H4W=EoOry6ww5rZnn6Ty_hfAs1zg-AFc1AYQ@mail.gmail.com>
 <ad836150-899b-459e-8b30-1ddb0c173064@oracle.com>
 <CAA-vtUwOAPo1OFj=T-KhFDSe5VAdR+NjT0PFeuvLVx6dg72MQw@mail.gmail.com>
 <c46874ee-2d6e-81ec-ea86-c88461e89d76@oracle.com>
Message-ID: <CAA-vtUxWFzLTRpOiaBQfSec0td3K8RKxzSbJHeVm_ct-=G1MSA@mail.gmail.com>

Hi Dan,

thanks a lot for the very thorough archeological dig!

The background for my question is that in the context of Lilliput I
experiment with replacing OM pointers with smaller-sized references. This
would mean we'd have to allocate them in an array or a confined address
space. That would require some form of global storage and raise the
question of allocation and deallocation contention. My current plan is to
deal with that using thread-local bulk operations, and so I arrive at
something that looks and feels similar to what existed before JDK-8253064.
It looks suspiciously simple, but the amount of work that went into the
original code feels like I may re-discover a lot of pitfalls. I also have
to understand why TSM stood in the way of JDK-8247281.

I'm still very much at the code reading and experimenting phase, so I don't
have more specific questions. If some come up, I'll ask again. Your history
lesson is very helpful.

Thanks!

Cheers, Thomas



On Mon, Jan 31, 2022 at 11:59 PM <daniel.daugherty at oracle.com> wrote:

> Greetings,
>
> I'm going to try and add some historical context here...
>
>
> On 1/31/22 3:09 AM, Thomas St?fe wrote:
> > Thanks a lot for your answers, David.
>
> Yes David, thanks for jumping in on this thread.
>
>
> > On Mon, Jan 31, 2022 at 8:35 AM David Holmes <david.holmes at oracle.com>
> > wrote:
> >
> >> On 31/01/2022 3:54 pm, Thomas St?fe wrote:
> >>> Hi David,
> >>>
> >>> Thank you for the answer!
> >>>
> >>> On Mon, Jan 31, 2022 at 6:23 AM David Holmes <david.holmes at oracle.com
> >>> <mailto:david.holmes at oracle.com>> wrote:
> >>>
> >>>      Hi Thomas,
> >>>
> >>>      On 31/01/2022 2:32 pm, Thomas St?fe wrote:
> >>>       > Hi,
> >>>       >
> >>>       > I have a small question about a detail of JDK-8253064.
> >>>       >
> >>>       > IIUC, before this patch, the VM kept thread-local freelists of
> >>>       > pre-allocated ObjectMonitors to reduce allocation contention.
> Now we just
> >>>       > malloc monitors right away.
> >>>       >
> >>>       > I looked through the issue and the associated PR, but could
> find no
> >>>       > information on why this was done. Dan describes what he did
> very well:
> >>>       > https://github.com/openjdk/jdk/pull/642#issuecomment-720753946,
> but not
> >>>       > why.
>
> Thank you and I'm sorry that my words on 8253064 did not explain the why.
>
>
> >>>       > I assume that the complexity and memory overhead of the free
> lists was not
> >>>       > worth it? That you found that malloc() is on our platforms
> "uncontented"
> >>>       > enough?
> >>>
> >>>      The issue was not about freelists and contention it was about
> requiring
> >>>      type-stable-memory: that once a piece of memory was allocated as
> an
> >>>      ObjectMonitor it remained forever after an ObjectMonitor. This
> allowed
> >>>      for various race conditions in the old monitor code maintaining
> safety.
>
> Erik Osterlund did have some specific reasons for getting rid of
> type-stable-memory.
> At least on reason was that it was complicating the work he wanted to do
> on:
>
>      JDK-8247281 migrate ObjectMonitor::_object to OopStorage
>      https://bugs.openjdk.java.net/browse/JDK-8247281
>
> He and I did work together to split this work into the various pieces that
> were integrated separately. So TSM didn't prevent work on JDK-8247281, but
> it did make it more difficult.
>
> Erik may have had other reasons for getting rid of TSM. I've added him to
> this email thread directly so he has a better chance of seeing this query.
>
>
>
> >>>      Over time that code changed substantially and the need for
> >>>      type-stable-memory for ObjectMonitors disappeared, so we finally
> got rid
> >>>      of it and just moved to a direct allocation scheme.
> >>>
> >>>
> >>> I think I understand, but I was specifically concerned with the
> question
> >>> of allocation contention of ObjectMonitors. That is somewhat
> independent
> >>> from the question of where OMs are allocated.
> >>>
> >>> Can it happen that lock inflation happens clustered, or does that not
> >>> occur in reality?
> >>>
> >>> AFAIU the old code managed OM storage itself, used global data
> >>> structures to do so, and guarded access with a mutex. To reduce
> >>> contention, it used a surprisingly large thread-local freelist of 1024
> >>> entries. This looks like contention was once a real problem.
>
> We need to take a step back and look at how we got where we are. There
> are (at least) four different evolutions or seismic events to this
> subsystem:
>
> 1) type-stable-memory and the global lists (block and free)
>    - JDK-5030359 "Back-end" synchronization improvements for 1.5.1 or 1.6
>      https://bugs.openjdk.java.net/browse/JDK-5030359
>    - integrated in jdk-6+50 (partial), jdk-6+53 (finished)
>
>    - This integration introduced type-stable-memory (TSM) and global block
>      and free-lists. Dice chose to not use malloc and use TSM for a few
>      reasons:
>      - direct control of the placement of the ObjectMonitor on a cache-line
>        boundary; couldn't trust malloc to keep memory properly aligned.
>      - malloc was slower than direct management of blocks of
> ObjectMonitors.
>      - Dice did lots of benchmarking to prove the new code was faster in
>        things we cared about at the time on the platforms we cared about.
>    - This predates my joining the Runtime team so I don't have exhaustive
>      records on this work.
>
> 2a) per-thread free list
>    - JDK-6468954 Generic synchronization cleanups for J2SE 1.7
>      https://bugs.openjdk.java.net/browse/JDK-6468954
>    - integrated in jdk-7+12
>
>    - This integration introduced the per-thread free list. This addition
>      was to deal with contention with allocating an ObjectMonitor from
>      the global free-list.
>    - Again, Dice did targeted benchmarking to show that adding a per-thread
>      free list  performed better for some specific platforms/configs.
>    - This predates my joining the Runtime team so I don't have exhaustive
>      records on this work.
>
> 2b) per-thread in-use list
>    - JDK-6852873 Increase in delta between application stopped time and
> ParNew GC time over application lifetime
>      https://bugs.openjdk.java.net/browse/JDK-6852873
>    - integrated in jdk-7+99
>
>    - This integration added the MonitorInUseLists concept and was done
>      as part of some work to deal with a safepoint performance problem.
>    - MonitorInUseLists was disabled by default.
>    - The benchmarking done here was focused on safepointing.
>    - I joined the Runtime team in Jan 2010, but I don't have exhaustive
>      records on this work.
>
> 2c) global in-use list
>    - JDK-6964164 +MonitorInUseLists can cause leakage of contended objects
>      https://bugs.openjdk.java.net/browse/JDK-6964164
>    - integrated in jdk-7+102
>
>    - This integration added the global in-use list since having just a
>      global block-list and global free-list had some races that caused
>      leaks.
>    - I joined the Runtime team in Jan 2010, but I don't have exhaustive
>      records of this work.
>
> 2d) MonitorInUseLists on by default
>    - JDK-8149442 MonitorInUseLists should be on by default, deflate idle
> monitors taking too long
>      https://bugs.openjdk.java.net/browse/JDK-8149442
>    - integrated in jdk-9+120
>
>    - This default switch flip was done to improve the safepoint time
>      it takes to deflate idle monitors. The benchmarks done were again
>      safepoint focused.
>
> 3) async monitor deflation
>     - JDK-8153224 Monitor deflation prolong safepoints
>       https://bugs.openjdk.java.net/browse/JDK-8153224
>     - This evolution switched to async deflation and lock-free lists and
>       was very complicated.
>     -
> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>     - integrated in jdk-15+26
>
>     - Again the focus was on reducing safepoint time. Lots of benchmarking
>       done with the perf group. We got faster safepoints, but had to really
>       fight to avoid regressions in artifically contended benchmarks which
>       is where the lock-free lists stuff came from.
>
> 4) monitor list simplifications and getting rid of TSM
>     - JDK-8253064 monitor list simplifications and getting rid of TSM
>       https://bugs.openjdk.java.net/browse/JDK-8253064
>     - integrated in jdk-16+24
>
>     - Not much to add here about 8253064. We wanted to get rid of TSM to
>       make other work simpler. Getting rid of TSM allowed us to switch to
>       much simpler list management logic. So we got rid of a lot of the
>       logic that we added with async monitor deflation (8153224).
>     - Lots of benchmarking done with the perf group and those
> pre-integration
>       benchmarks showed no worrisome regressions and some speedups.
>     - Later benchmarking showed some regressions (that have since been
> fixed)
>       and we never figured out why we had different results later
> compared to
>       the pre-integration benchmarks. One theory is that we see different
>       results in AMD-X64 versus Intel-X64.
>
>
> >> You can always create a benchmark to show contention in the monitor
> >> inflation code. I don't recall now whether this was a real issue or a
> >> microbenchmark issue. As the code stated:
> >>
> >> ObjectMonitor * ATTR ObjectSynchronizer::omAlloc (Thread * Self) {
> >>       // A large MAXPRIVATE value reduces both list lock contention
> >>       // and list coherency traffic, but also tends to increase the
> >>       // number of objectMonitors in circulation as well as the STW
> >>       // scavenge costs.  As usual, we lean toward time in space-time
> >>       // tradeoffs.
> >>
> >>       const int MAXPRIVATE = 1024 ;
> >>
> >> so general performance was a consideration.
> >>
> >>> OTOH the new code just uses malloc, which also may lock depending on
> the
> >>> malloc allocator internals and the used libc settings. Therefore I
> >>> wonder whether OM allocation is still a problem, not a problem with
> >>> real-life malloc, or maybe never really had been a problem and the old
> >>> code was just overly cautious?
> >> Whenever we make significant changes to a subsystem we always
> >> investigate the performance profile of the changes. We're prepared to
> >> accept some performance loss if we have a good improvement in code
> >> complexity/maintainability etc, but if a significant performance issue
> >> arose we would revisit it. See for example discussion in:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8263864
> >>
> >> and related.
>
> We have not seen any performance regressions that we can attribute to
> malloc lock contention. In fact, I had to put upper limits on my personal
> ObjectMonitor inflation stress programs because they could allocate
> inflated ObjectMonitors so fast that the MonitorDeflationThread could
> not keep up. You'll notice that the deflation code now stops its
> current loop at 1 million objects and takes a check-for-a-safepoint
> breather. So I would say that malloc() of ObjectMonitor is not a
> performance issue any longer. I believe Dice said that it was before
> back in the JDK6 days, but no longer...
>
>
> Hopefully some of this history stuff is useful.
>
> Dan
>
>
>
> >>
> >> Cheers,
> >> David
> >> -----
> >>
> >>> Thanks, Thomas
> >>>
> >>>
>
>

From adinn at openjdk.java.net  Wed Feb  2 16:13:14 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Wed, 2 Feb 2022 16:13:14 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
Message-ID: <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>

On Tue, 1 Feb 2022 16:23:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @kimbarrett - Thanks for the review! Good catch! I believe you are correct,
>> but let's wait for @adinn to chime in here.
>
> Returning 0 if count == 0 and bits otherwise is consistent with the old code,
> assuming the problematic shift doesn't cause UB data corruption or something
> otherwise strange.  It might do the "mathematically correct" thing of shifting
> out all the bits (so zeroing the value).  Another possibility is that the
> implemented shift amount for N is N mod word-size (some platforms do that, but
> I haven't looked up aarch64), which in this case is 64 mod 64, or 0.  I don't
> think there are any other non-strange non-UB-data-corruption possibilities.
> 
> 
> result is initially 0.
> with the old code:
> - if count == 0, there are no iterations, and final result is still 0.
> - if count == 1, there is one iteration.
>   result <<= nbits
>     -- if UB corruption, all bets are off
>     -- if shifts by 64, result is unchanged (== 0)
>     -- if shifts by 64 mod 64 (== 0), result is unchanged (== 0)
>   result |= (bits & mask)
>     -- result == bits
> - if count > 1, for additional iterations
>   result <<= nbits
>     -- if UB corruption, all bets are off
>     -- if shifts by 64, result == 0
>     -- if shifts by 64 mod 64 (== 0), result is unchanged (== bits)
>   result |= (bits & mask)
>     -- result == bits
> 
> So with old code, for count > 0, result == bits (or UB corrupted data).

First thing to note is that `replicate` is never actually called with `count == 0`. It's questionable whether it ever should be (especially as this function is really only meant to be used locally to this code) but logically I think the result ought to be 0 if it ever does get called that way.

What `replicate` is meant to do is replicate the bottom `nbits` bits of the `uint64_t` passed via argument `bits` across successive subfields of `result` up to `(count * bits)` worth of bits (sorry ... the names are somewhat inconveniently chosen as far as this discussion is concerned). So, anyway, a count of zero ought to insert 0 bits giving a zero result.

As to how it is used, `replicate` is only called from method `expandLogicalImmediate` with two alternative calling patterns. It is sometimes called like this

    for (int i = 0; i < 6; i++) {
      int nbits = 1 << i;
      . . .
        replicate(and_bit, 1, nbits)

n.b. argument `count` is being supplied as `nbits` and argument `nbits` is supplied as 1 (yeah, naming is hard). These calls serve to insert anywhere between 1 and 32 copies of a single bit into the rightmost portion of the result.

It is also called like this:

    for (int i = 0; i < 6; i++) {
      int nbits = 1 << i;
      . . .
          replicate(and_bits_top, 2 * nbits, 32 / nbits)

This is used to replicate a bit pattern taken from the lower end of the first input across the whole of a uint64_t result. For these calls the input arguments `count` and `nbits` satisfy the following invariants:

    nbits | 64
    count | 64
    nbits * count == 64
    2 <= nbits <= 32
    32 >= count >= 2

I am not actually clear why the caller is calling `replicate` in the way it does. The algorithm is way more complicated than it actually needs to be. The basic idea is to insert imms 1s into a 2^k bit field, right rotate them by immr and then replicate the result across the full 64 bits. There's a few wrinkles which are explained here for those who are interested:

expandLogicalImmediate(uint32_t immN, uint32_t immr, uint32_t imms, uint64_t& bimm)

-  outputs a bit pattern of width 64 by replicating a bit field of width 2^k and returns 1 or fails and returns 0

- when immN is 1 then k is 6 and immr/imms are masked to 6 bit integers.
- when immN is 0 then k is the count of the first 0 bit in imms and immr/imms are masked to k-bit integers (i.e. leading 1s in imms determine dead bits of imms and immr)

A k value of 0 (i.e. immN == 0 and imms = all 1s) fails and returns 0

After masking

An imms value of all 1s (i.e. 2^k - 1) fails and returns 0 (note given the previous check we only get here when  immN == 1)

The bit field can now be constructed as follows:

 - imms + 1 specifies the number of 1s to insert into the 2^k-field (note that imms + 1 < 2^k)
 - immr counts how far to right rotate the 2^k-field

The resulting 2^k-field is then replicated across the full 64-bit result.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From duke at openjdk.java.net  Wed Feb  2 16:30:56 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 2 Feb 2022 16:30:56 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v18]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:

  Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/3618a77d..4ab28477

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=16-17

  Stats: 8 lines in 1 file changed: 2 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885

From duke at openjdk.java.net  Wed Feb  2 16:30:59 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 2 Feb 2022 16:30:59 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v13]
In-Reply-To: <AHgTd1B4suatGGDI5s3L3k12Y9SekLMpwMtu5aR8g8E=.6fd22c94-f0c4-4c4f-a7ba-c3edf9921d79@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <BYYFJseyaER7rP7ni6tMgPoSvWBn--qr-Xv2bkXkDLA=.ecd6ba16-88e5-458c-9203-a715ba69ba3a@github.com>
 <AHgTd1B4suatGGDI5s3L3k12Y9SekLMpwMtu5aR8g8E=.6fd22c94-f0c4-4c4f-a7ba-c3edf9921d79@github.com>
Message-ID: <iu1oFn1FEGk5-3qblw4DejFig0QpN4e3wkgjPSJGoLw=.d3bc84e0-36cf-40e8-8d07-34e02b8c80aa@github.com>

On Fri, 21 Jan 2022 22:48:20 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Tyler Steele has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp line 63:
> 
>> 61: 
>> 62:     if (ret_frame.pc() == NULL) {
>> 63:       // ucontext wasn't useful
> 
> Null check has been moved before frame constructor in head revision.

Thanks for the reminder. I made this change in a recent push.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From mdoerr at openjdk.java.net  Wed Feb  2 17:20:17 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 2 Feb 2022 17:20:17 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v18]
In-Reply-To: <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@github.com>
Message-ID: <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>

On Wed, 2 Feb 2022 16:30:56 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler

Thanks for the update. As David had written, the Oracle Copyright lines you have added are not correct: "Copyright (c) 2022, 2022". I suggest to avoid adding new lines for this change until the topic is clarified.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From dcubed at openjdk.java.net  Wed Feb  2 20:14:12 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 2 Feb 2022 20:14:12 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
Message-ID: <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>

On Wed, 2 Feb 2022 16:09:50 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Returning 0 if count == 0 and bits otherwise is consistent with the old code,
>> assuming the problematic shift doesn't cause UB data corruption or something
>> otherwise strange.  It might do the "mathematically correct" thing of shifting
>> out all the bits (so zeroing the value).  Another possibility is that the
>> implemented shift amount for N is N mod word-size (some platforms do that, but
>> I haven't looked up aarch64), which in this case is 64 mod 64, or 0.  I don't
>> think there are any other non-strange non-UB-data-corruption possibilities.
>> 
>> 
>> result is initially 0.
>> with the old code:
>> - if count == 0, there are no iterations, and final result is still 0.
>> - if count == 1, there is one iteration.
>>   result <<= nbits
>>     -- if UB corruption, all bets are off
>>     -- if shifts by 64, result is unchanged (== 0)
>>     -- if shifts by 64 mod 64 (== 0), result is unchanged (== 0)
>>   result |= (bits & mask)
>>     -- result == bits
>> - if count > 1, for additional iterations
>>   result <<= nbits
>>     -- if UB corruption, all bets are off
>>     -- if shifts by 64, result == 0
>>     -- if shifts by 64 mod 64 (== 0), result is unchanged (== bits)
>>   result |= (bits & mask)
>>     -- result == bits
>> 
>> So with old code, for count > 0, result == bits (or UB corrupted data).
>
> First thing to note is that `replicate` is never actually called with `count == 0`. It's questionable whether it ever should be (especially as this function is really only meant to be used locally to this code) but logically I think the result ought to be 0 if it ever does get called that way.
> 
> What `replicate` is meant to do is replicate the bottom `nbits` bits of the `uint64_t` passed via argument `bits` across successive subfields of `result` up to `(count * bits)` worth of bits (sorry ... the names are somewhat inconveniently chosen as far as this discussion is concerned). So, anyway, a count of zero ought to insert 0 bits giving a zero result.
> 
> As to how it is used, `replicate` is only called from method `expandLogicalImmediate` with two alternative calling patterns. It is sometimes called like this
> 
>     for (int i = 0; i < 6; i++) {
>       int nbits = 1 << i;
>       . . .
>         replicate(and_bit, 1, nbits)
> 
> n.b. argument `count` is being supplied as `nbits` and argument `nbits` is supplied as 1 (yeah, naming is hard). These calls serve to insert anywhere between 1 and 32 copies of a single bit into the rightmost portion of the result.
> 
> It is also called like this:
> 
>     for (int i = 0; i < 6; i++) {
>       int nbits = 1 << i;
>       . . .
>           replicate(and_bits_top, 2 * nbits, 32 / nbits)
> 
> This is used to replicate a bit pattern taken from the lower end of the first input across the whole of a uint64_t result. For these calls the input arguments `count` and `nbits` satisfy the following invariants:
> 
>     nbits | 64
>     count | 64
>     nbits * count == 64
>     2 <= nbits <= 32
>     32 >= count >= 2
> 
> I am not actually clear why the caller is calling `replicate` in the way it does. The algorithm is way more complicated than it actually needs to be. The basic idea is to insert imms 1s into a 2^k bit field, right rotate them by immr and then replicate the result across the full 64 bits. There's a few wrinkles which are explained here for those who are interested:
> 
> expandLogicalImmediate(uint32_t immN, uint32_t immr, uint32_t imms, uint64_t& bimm)
> 
> -  outputs a bit pattern of width 64 by replicating a bit field of width 2^k and returns 1 or fails and returns 0
> 
> - when immN is 1 then k is 6 and immr/imms are masked to 6 bit integers.
> - when immN is 0 then k is the count of the first 0 bit in imms and immr/imms are masked to k-bit integers (i.e. leading 1s in imms determine dead bits of imms and immr)
> 
> A k value of 0 (i.e. immN == 0 and imms = all 1s) fails and returns 0
> 
> After masking
> 
> An imms value of all 1s (i.e. 2^k - 1) fails and returns 0 (note given the previous check we only get here when  immN == 1)
> 
> The bit field can now be constructed as follows:
> 
>  - imms + 1 specifies the number of 1s to insert into the 2^k-field (note that imms + 1 < 2^k)
>  - immr counts how far to right rotate the 2^k-field
> 
> The resulting 2^k-field is then replicated across the full 64-bit result.

@adinn - Thanks for chiming in on this review thread.

I'm reading and re-reading your comments and it will take me a while
to put it all in proper context.

I do agree with one of your points:

> `replicate` is never actually called with `count == 0`

so that means that this:

    `assert(count <= 1, "must be");`

is a little too loose and should change to:

    `assert(count == 1, "must be");`

if we're going to keep it at all. I think we should keep it, but
I can be convinced otherwise since the original code had no
similar `assert()`.

@kimbarrett - I've re-read your comments and I'm not clear
on whether you think that `result <<= nbits` is UB when
`nbits == 64`. Can you please clarify?

Of course, it's not helping matters that I can't reproduce the
failure mode reported by Apple and we're getting no response
about our request for version info.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From duke at openjdk.java.net  Wed Feb  2 22:08:44 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Wed, 2 Feb 2022 22:08:44 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available
Message-ID: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>

Hi Team,

In this patch I have fixed two issues related to large pages, following is the summary of changes :-

1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.

?
Please find below the performance data with and without patch for the JMH benchmark included with the patch.

![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)


Please review and provide your valuable comments.



Thanks,
Swati Sharma
Runtime Software Development Engineer 
Intel

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

Commit messages:
 - 8271195: Resolving jcheck failure.
 - 8271195: Use largest available large page size smaller than LargePageSizeInBytes when available

Changes: https://git.openjdk.java.net/jdk/pull/7326/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271195
  Stats: 352 lines in 5 files changed: 323 ins; 21 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Wed Feb  2 22:42:47 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 2 Feb 2022 22:42:47 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:

  Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6885/files
  - new: https://git.openjdk.java.net/jdk/pull/6885/files/4ab28477..0551e65e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=17-18

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885

From duke at openjdk.java.net  Wed Feb  2 22:42:48 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 2 Feb 2022 22:42:48 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v18]
In-Reply-To: <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@github.com>
 <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>
Message-ID: <6ol-wPa7GrBaEpVwy2Pqx547qDZ3iCv28itzlLksc1Q=.76921069-30a7-42db-9c7c-dc65d1876418@github.com>

On Wed, 2 Feb 2022 17:17:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks for the update. As David had written, the Oracle Copyright lines you have added are not correct: "Copyright (c) 2022, 2022". I suggest to avoid adding new lines for this change until the topic is clarified.

Agreed. I have removed the incorrect header line and will add a new one when I receive clarification.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From minqi at openjdk.java.net  Thu Feb  3 02:56:25 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 3 Feb 2022 02:56:25 GMT
Subject: RFR: 8280767: -XX:ArchiveClassesAtExit does not archive
 BoundMethodHandle$Species classes
Message-ID: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>

Hi, Please review

  When do dynamic dump, the call to LambdaForInvolkers::append_filtered for generating lambda holder classes will only allow the result which matches the filtering list to be added . This filters out the SPECIES method handle holder classes, and they won't be archived in dynamic shared archive. The patch is doing followings:
  1) Removed the call to  LambdaForInvolkers::append_filtered, instead just call LambdaForInvolkers::append so the SPECIES can be added to the regeneration list.
  2) Added an enum for  shared flag in Klass, _generated to indicate the class is regenerated and it should not be loaded from CDS if CFLH is enabled. If the class is a SPECIES and also loaded from base archive, skip regenerating it for dynamic archive.
  3) Removed SystemDictionaryShared::is_hidden_lambda_proxy since it is only used in one place where checking CFLH  --- moved the checking code into KlassFactory::check_shared_class_file_load_hook to make code cleaner.

Tests: tier1,tier4

Thanks
Yumin

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

Commit messages:
 - Fix white space
 - Merge branch 'master' into jdk-8280767
 - 8280767: -XX:ArchiveClassesAtExit does not archive BoundMethodHandle classes

Changes: https://git.openjdk.java.net/jdk/pull/7329/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7329&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280767
  Stats: 194 lines in 10 files changed: 159 ins; 22 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7329.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7329/head:pull/7329

PR: https://git.openjdk.java.net/jdk/pull/7329

From kbarrett at openjdk.java.net  Thu Feb  3 04:37:05 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 3 Feb 2022 04:37:05 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
Message-ID: <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>

On Wed, 2 Feb 2022 20:11:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> First thing to note is that `replicate` is never actually called with `count == 0`. It's questionable whether it ever should be (especially as this function is really only meant to be used locally to this code) but logically I think the result ought to be 0 if it ever does get called that way.
>> 
>> What `replicate` is meant to do is replicate the bottom `nbits` bits of the `uint64_t` passed via argument `bits` across successive subfields of `result` up to `(count * bits)` worth of bits (sorry ... the names are somewhat inconveniently chosen as far as this discussion is concerned). So, anyway, a count of zero ought to insert 0 bits giving a zero result.
>> 
>> As to how it is used, `replicate` is only called from method `expandLogicalImmediate` with two alternative calling patterns. It is sometimes called like this
>> 
>>     for (int i = 0; i < 6; i++) {
>>       int nbits = 1 << i;
>>       . . .
>>         replicate(and_bit, 1, nbits)
>> 
>> n.b. argument `count` is being supplied as `nbits` and argument `nbits` is supplied as 1 (yeah, naming is hard). These calls serve to insert anywhere between 1 and 32 copies of a single bit into the rightmost portion of the result.
>> 
>> It is also called like this:
>> 
>>     for (int i = 0; i < 6; i++) {
>>       int nbits = 1 << i;
>>       . . .
>>           replicate(and_bits_top, 2 * nbits, 32 / nbits)
>> 
>> This is used to replicate a bit pattern taken from the lower end of the first input across the whole of a uint64_t result. For these calls the input arguments `count` and `nbits` satisfy the following invariants:
>> 
>>     nbits | 64
>>     count | 64
>>     nbits * count == 64
>>     2 <= nbits <= 32
>>     32 >= count >= 2
>> 
>> I am not actually clear why the caller is calling `replicate` in the way it does. The algorithm is way more complicated than it actually needs to be. The basic idea is to insert imms 1s into a 2^k bit field, right rotate them by immr and then replicate the result across the full 64 bits. There's a few wrinkles which are explained here for those who are interested:
>> 
>> expandLogicalImmediate(uint32_t immN, uint32_t immr, uint32_t imms, uint64_t& bimm)
>> 
>> -  outputs a bit pattern of width 64 by replicating a bit field of width 2^k and returns 1 or fails and returns 0
>> 
>> - when immN is 1 then k is 6 and immr/imms are masked to 6 bit integers.
>> - when immN is 0 then k is the count of the first 0 bit in imms and immr/imms are masked to k-bit integers (i.e. leading 1s in imms determine dead bits of imms and immr)
>> 
>> A k value of 0 (i.e. immN == 0 and imms = all 1s) fails and returns 0
>> 
>> After masking
>> 
>> An imms value of all 1s (i.e. 2^k - 1) fails and returns 0 (note given the previous check we only get here when  immN == 1)
>> 
>> The bit field can now be constructed as follows:
>> 
>>  - imms + 1 specifies the number of 1s to insert into the 2^k-field (note that imms + 1 < 2^k)
>>  - immr counts how far to right rotate the 2^k-field
>> 
>> The resulting 2^k-field is then replicated across the full 64-bit result.
>
> @adinn - Thanks for chiming in on this review thread.
> 
> I'm reading and re-reading your comments and it will take me a while
> to put it all in proper context.
> 
> I do agree with one of your points:
> 
>> `replicate` is never actually called with `count == 0`
> 
> so that means that this:
> 
>     `assert(count <= 1, "must be");`
> 
> is a little too loose and should change to:
> 
>     `assert(count == 1, "must be");`
> 
> if we're going to keep it at all. I think we should keep it, but
> I can be convinced otherwise since the original code had no
> similar `assert()`.
> 
> @kimbarrett - I've re-read your comments and I'm not clear
> on whether you think that `result <<= nbits` is UB when
> `nbits == 64`. Can you please clarify?
> 
> Of course, it's not helping matters that I can't reproduce the
> failure mode reported by Apple and we're getting no response
> about our request for version info.

It's definitely UB according to the language.  Then there's the question of what the hardware might actually implement in the cases where the compiler doesn't recognize it and the relevant instruction(s) are executed with that value.  I know I've seen hardware that used the shift quantity mod word-size.  I think I've seen hardware that would just shift out all the bits, leaving a value of 0.  One reason for the language to make this UB is because of hardware variance.  Oh, and I *think* I've seen hardware where it was UB and would produce "strange" results.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From stuefe at openjdk.java.net  Thu Feb  3 05:25:38 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 3 Feb 2022 05:25:38 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy
Message-ID: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>

release_multi_mappings_vm is unfortunately racy.

The original intention of the test was to check that `os::release_memory()` works across multiple mappings allocated with multiple calls to `os::reserve_memory()`. This was broken for a long time on windows, since it relies on the implicit assumption that every platform uses mmap-ish APIs under the hood. But Windows virtual memory API (and SysV shmat, for that matter) does not work that way.

The release_multi_mappings_vm test 
- A reserves a number of mappings in 4M stripes adjacent to each other 
- B releases them with a single call to os::release_memory
- C re-allocates a range at the same address

Step (C) will fail if the os::release call in (B) failed to release the mapping. Which it sometimes did silently, so just checking the return code in (B) was not sufficient.

Unfortunately, it will also fail if someone concurrently mapped into the range between (B) and (C). It's rare, but it happens.

This is difficult to make completely airtight, but we could make it much more stable:
1) instead of releasing all stripes, just release the n middle stripes (n>1) and leave first and last stripe reserved. Then, in (C), re-reserve the middle stripes. Tests the same (as long as we have multiple middle stripes) but drastically decreases the chance of some random allocation placing memory into the vacated address hole
2) reduce the stripe size from today's 4M to something much smaller. Again, reduces the chance of stray mappings being placed into the hole since it will be smaller too.

The patch does just that.
It also adds a lengthy comment.
I also needed to place the NUMASwitchter line to the front of the function since now the last os::release_memory - done to clean up everything before the tests ends - is a multi-mapping-release too (we now release front stripe, middle, and end stripe).

Tests:
- GHAs
- manually ran the test on x64 Linux
- SAP nightlies

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

Commit messages:
 - start

Changes: https://git.openjdk.java.net/jdk/pull/7288/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7288&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280940
  Stats: 35 lines in 1 file changed: 24 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7288.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7288/head:pull/7288

PR: https://git.openjdk.java.net/jdk/pull/7288

From adinn at openjdk.java.net  Thu Feb  3 10:26:16 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 3 Feb 2022 10:26:16 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
Message-ID: <iN51kmLhkEiLGLZL6VRYYJRe_-EpT2j-Ew2itxDj95w=.cd02560a-bbe1-4ddd-a4ee-f49ebeb49fbb@github.com>

On Thu, 3 Feb 2022 04:32:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @adinn - Thanks for chiming in on this review thread.
>> 
>> I'm reading and re-reading your comments and it will take me a while
>> to put it all in proper context.
>> 
>> I do agree with one of your points:
>> 
>>> `replicate` is never actually called with `count == 0`
>> 
>> so that means that this:
>> 
>>     `assert(count <= 1, "must be");`
>> 
>> is a little too loose and should change to:
>> 
>>     `assert(count == 1, "must be");`
>> 
>> if we're going to keep it at all. I think we should keep it, but
>> I can be convinced otherwise since the original code had no
>> similar `assert()`.
>> 
>> @kimbarrett - I've re-read your comments and I'm not clear
>> on whether you think that `result <<= nbits` is UB when
>> `nbits == 64`. Can you please clarify?
>> 
>> Of course, it's not helping matters that I can't reproduce the
>> failure mode reported by Apple and we're getting no response
>> about our request for version info.
>
> It's definitely UB according to the language.  Then there's the question of what the hardware might actually implement in the cases where the compiler doesn't recognize it and the relevant instruction(s) are executed with that value.  I know I've seen hardware that used the shift quantity mod word-size.  I think I've seen hardware that would just shift out all the bits, leaving a value of 0.  One reason for the language to make this UB is because of hardware variance.  Oh, and I *think* I've seen hardware where it was UB and would produce "strange" results.

> I do agree with one of your points:
>
> > replicate is never actually called with count == 0
>
> so that means that this:
>
> >     assert(count <= 1, "must be");
>
> is a little too loose and should change to:
>
> >     assert(count == 1, "must be");
>
> if we're going to keep it at all. I think we should keep it, but
> I can be convinced otherwise since the original code had no similar assert().

That is entirely reasonable given that replicate is only meant to be used locally and none of these local use cases will ever try to replicate 0 copies of a bit field.

We could actually add one or both of these more general asserts at entry to `replicate` since they apply to all cases, not just when `nbits == 64`:

    assert(count > 0, "must be")
    assert(count * nbits <= 64, "must be")

In other words it is an error to try to replicate zero copies of a bit field and it is an error to try to replicate more copies than can fit into 64 bits.

Note that the second assert removes the need for the current assert and combining it with the first assert also enforces your recommended alternative.

We could also add another general assert

    assert(nbits > 0, "must be")

i.e. it is an error to try to replicate an empty bit field.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From mdoerr at openjdk.java.net  Thu Feb  3 11:17:16 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 3 Feb 2022 11:17:16 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
Message-ID: <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>

On Wed, 2 Feb 2022 22:42:47 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp

Looks good to me, too. I think it is ready for integration assuming all change requests were taken care of and tests have passed.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6885

From stuefe at openjdk.java.net  Thu Feb  3 11:25:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 3 Feb 2022 11:25:15 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
 <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>
Message-ID: <WNVSezqF2f-7JUgyAm84PmtU1EVRPF0KJPALz_qNYM8=.376c4ede-9d09-4d6f-85dc-af043a4eeacf@github.com>

On Thu, 3 Feb 2022 11:14:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Looks good to me, too. I think it is ready for integration assuming all change requests were taken care of and tests have passed.

@TheRealMDoerr we should test the latest version of this patch in our nightlies, just in case

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From ayang at openjdk.java.net  Thu Feb  3 16:56:13 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 3 Feb 2022 16:56:13 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>

On Wed, 2 Feb 2022 15:58:53 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Changes requested by ayang (Reviewer).

src/hotspot/os/linux/os_linux.cpp line 3782:

> 3780:       os::Linux::setup_large_page(page_size)) {
> 3781:       _large_page_size = page_size;
> 3782:       large_page_found = true;

I don't think this is at the right level: here we don't yet know which kind of large page to use, which is decided in `os::Linux::setup_large_page_type` (the original name).

Instead, the fix should be inside `hugetlbfs_sanity_check`, sth like:


for (local_page_size = page_size; page_size_ != (size_t)os::vm_page_size(); local_page_size = _page_sizes.next_smaller(local_page_size) {
  if (try_commit_using_large_page(local_page_size)) {
    _large_page_size = local_page_size;
    return true;
  }
}

return false;

src/hotspot/os/linux/os_linux.cpp line 4038:

> 4036:   if (!large_committed) {
> 4037:     // Failed to commit large pages, so we need to unmap the whole reservation.
> 4038:     ::munmap(aligned_start, bytes);

I don't understand why this change is related to this ticket/PR, or needed at all.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From dcubed at openjdk.java.net  Thu Feb  3 17:25:05 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Feb 2022 17:25:05 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
Message-ID: <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>

On Thu, 3 Feb 2022 04:32:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @adinn - Thanks for chiming in on this review thread.
>> 
>> I'm reading and re-reading your comments and it will take me a while
>> to put it all in proper context.
>> 
>> I do agree with one of your points:
>> 
>>> `replicate` is never actually called with `count == 0`
>> 
>> so that means that this:
>> 
>>     `assert(count <= 1, "must be");`
>> 
>> is a little too loose and should change to:
>> 
>>     `assert(count == 1, "must be");`
>> 
>> if we're going to keep it at all. I think we should keep it, but
>> I can be convinced otherwise since the original code had no
>> similar `assert()`.
>> 
>> @kimbarrett - I've re-read your comments and I'm not clear
>> on whether you think that `result <<= nbits` is UB when
>> `nbits == 64`. Can you please clarify?
>> 
>> Of course, it's not helping matters that I can't reproduce the
>> failure mode reported by Apple and we're getting no response
>> about our request for version info.
>
> It's definitely UB according to the language.  Then there's the question of what the hardware might actually implement in the cases where the compiler doesn't recognize it and the relevant instruction(s) are executed with that value.  I know I've seen hardware that used the shift quantity mod word-size.  I think I've seen hardware that would just shift out all the bits, leaving a value of 0.  One reason for the language to make this UB is because of hardware variance.  Oh, and I *think* I've seen hardware where it was UB and would produce "strange" results.

@kimbarrett - Thanks for confirming that we have UB here.

@adinn - I'll take a look and updating the `assert()` calls and retest.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From dcubed at openjdk.java.net  Thu Feb  3 20:36:11 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Feb 2022 20:36:11 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy
In-Reply-To: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
Message-ID: <wmj_Mj80-HfOJSMSvHmNFOO_LiP-hjRqu7G5-fZPz-o=.330fa604-25b1-4c5c-ab65-7f01eedd17df@github.com>

On Mon, 31 Jan 2022 12:20:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> release_multi_mappings_vm is unfortunately racy.
> 
> The original intention of the test was to check that `os::release_memory()` works across multiple mappings allocated with multiple calls to `os::reserve_memory()`. This was broken for a long time on windows, since it relies on the implicit assumption that every platform uses mmap-ish APIs under the hood. But Windows virtual memory API (and SysV shmat, for that matter) does not work that way.
> 
> The release_multi_mappings_vm test 
> - A reserves a number of mappings in 4M stripes adjacent to each other 
> - B releases them with a single call to os::release_memory
> - C re-allocates a range at the same address
> 
> Step (C) will fail if the os::release call in (B) failed to release the mapping. Which it sometimes did silently, so just checking the return code in (B) was not sufficient.
> 
> Unfortunately, it will also fail if someone concurrently mapped into the range between (B) and (C). It's rare, but it happens.
> 
> This is difficult to make completely airtight, but we could make it much more stable:
> 1) instead of releasing all stripes, just release the n middle stripes (n>1) and leave first and last stripe reserved. Then, in (C), re-reserve the middle stripes. Tests the same (as long as we have multiple middle stripes) but drastically decreases the chance of some random allocation placing memory into the vacated address hole
> 2) reduce the stripe size from today's 4M to something much smaller. Again, reduces the chance of stray mappings being placed into the hole since it will be smaller too.
> 
> The patch does just that.
> It also adds a lengthy comment.
> I also needed to place the NUMASwitchter line to the front of the function since now the last os::release_memory - done to clean up everything before the tests ends - is a multi-mapping-release too (we now release front stripe, middle, and end stripe).
> 
> Tests:
> - GHAs
> - manually ran the test on x64 Linux
> - SAP nightlies

Thumbs up.

You may want to correct 'NUMASwitchter' in the PR so that
any searches find the correct name.

test/hotspot/gtest/runtime/test_os.cpp line 490:

> 488:   PRINT_MAPPINGS("B");
> 489: 
> 490:   // ...re-reserve the middle stripes. This should work unless release failed.

Perhaps:
    s/failed/failed silently/

just to be clear.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7288

From dcubed at openjdk.java.net  Thu Feb  3 21:05:37 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Feb 2022 21:05:37 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
Message-ID: <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>

> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
> replicate().
> 
> I was not able to reproduce the reported failure using:
> 
>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
> 
> so I'm moving forward with the proposed fix from a code inspection
> point of view.
> 
> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
> no failures. Tier[3-6] are still running.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  kimbarrett and adinn CR changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7270/files
  - new: https://git.openjdk.java.net/jdk/pull/7270/files/562ceb51..e4afa9e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7270&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7270&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From dcubed at openjdk.java.net  Thu Feb  3 21:08:09 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Feb 2022 21:08:09 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
Message-ID: <imOW0nQqUWMXz3YBko0rX5Mp7ooBGgVtCbjdQA_fvGQ=.d15de1cd-8f3f-4612-8195-1abfa8654f37@github.com>

On Fri, 28 Jan 2022 16:49:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
> replicate().
> 
> I was not able to reproduce the reported failure using:
> 
>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
> 
> so I'm moving forward with the proposed fix from a code inspection
> point of view.
> 
> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
> no failures. Tier[3-6] are still running.

The v01 changes have passed Mach5 Tier1.
Mach5 Tier[23] are still running.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From minqi at openjdk.java.net  Thu Feb  3 22:26:57 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 3 Feb 2022 22:26:57 GMT
Subject: RFR: 8280767: -XX:ArchiveClassesAtExit does not archive
 BoundMethodHandle$Species classes [v2]
In-Reply-To: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
References: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
Message-ID: <zVW-nr_7Lfr2stFYg_g1f_mqtCwBqt0EiW8nj_zYKP4=.0719db9b-6f10-4b67-9671-3389827d9861@github.com>

> Hi, Please review
> 
>   When do dynamic dump, the call to LambdaForInvolkers::append_filtered for generating lambda holder classes will only allow the result which matches the filtering list to be added . This filters out the SPECIES method handle holder classes, and they won't be archived in dynamic shared archive. The patch is doing followings:
>   1) Removed the call to  LambdaForInvolkers::append_filtered, instead just call LambdaForInvolkers::append so the SPECIES can be added to the regeneration list.
>   2) Added an enum for  shared flag in Klass, _generated to indicate the class is regenerated and it should not be loaded from CDS if CFLH is enabled. If the class is a SPECIES and also loaded from base archive, skip regenerating it for dynamic archive.
>   3) Removed SystemDictionaryShared::is_hidden_lambda_proxy since it is only used in one place where checking CFLH  --- moved the checking code into KlassFactory::check_shared_class_file_load_hook to make code cleaner.
> 
> Tests: tier1,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Avoid call CFLH for regenerated lambda holder classes, reversed change for is_hidden_lambda_proxy

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7329/files
  - new: https://git.openjdk.java.net/jdk/pull/7329/files/52099534..8f1d356c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7329&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7329&range=00-01

  Stats: 30 lines in 4 files changed: 19 ins; 6 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7329.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7329/head:pull/7329

PR: https://git.openjdk.java.net/jdk/pull/7329

From duke at openjdk.java.net  Fri Feb  4 00:25:43 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Feb 2022 00:25:43 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into JDK-8203290
 - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
 - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
 - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
 - Addresses issues from review and other sm fixes
   
   - Adds commenting in regards to memory handling by SystemProcess &
   NetworkInterface classes
   - Replaces explicit initialization and copy of structs with memcpy
   and memset as appropriate
   - Renames internal struct definitions in os_perf_aix
   - Other minor fixes
 - Changes macoss -> macosx in problem list
 - Refactors loadlib_aix: Removes redundant c++ class
 - Merge branch 'master' into JDK-8203290
 - Implements JFR on AIX
   
   - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
   - Updates libperfstat_aix to contain functionality needed by os_perf_aix
   - Implements missing functionality in loadlib_aix (Fixes failure noted
   by TestNativeLibraies.java)
   - Removes platform checks for --enable-feature-jfr (Now enable-able on
   all platforms)
   - Enables TestNetworkUtilizationEvent.java which now passes on AIX
   - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

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

Changes: https://git.openjdk.java.net/jdk/pull/6885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=19
  Stats: 1235 lines in 10 files changed: 466 ins; 502 del; 267 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885

From duke at openjdk.java.net  Fri Feb  4 00:34:17 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Feb 2022 00:34:17 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v18]
In-Reply-To: <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <-MGVE0ejBqUJiNPf_eDSNVHCzkq-R-FXN9bvGtAF8gM=.f628d9f3-ab59-4f81-8c9b-b1b3536b5561@github.com>
 <PNaiFDYyjxVTWkdhJIesDTegW0m2yFpj5-mzYQqjbbE=.cc65cfbd-2629-4af1-8bd6-1c62f1677848@github.com>
Message-ID: <he54ulCsnFWkTs-HA3_fAiz7gqNwIf4uDsEBt19la2o=.1f9aad0f-25e8-4993-828c-2d8637e0fbe4@github.com>

On Wed, 2 Feb 2022 17:17:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>
> Thanks for the update. As David had written, the Oracle Copyright lines you have added are not correct: "Copyright (c) 2022, 2022". I suggest to avoid adding new lines for this change until the topic is clarified.

I received some guidance from our legal team. They suggested that I add the Oracle copyright header to files that only had the SAP header if I have made changes. They also suggested adding an IBM copyright line to files I have modified as well. @TheRealMDoerr, I know you also reached out to Iris. Have you heard back from them?

I'm a fan of more testing @tstuefe. Let me know if you discover anything interesting.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From kbarrett at openjdk.java.net  Fri Feb  4 00:41:10 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Feb 2022 00:41:10 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
Message-ID: <6QFfnnjE6YXTPDRdl0S0pDos0getybxhb-NjEqs-y8A=.6eba0758-8ab3-43dd-9f0c-8db5dcaa1657@github.com>

On Thu, 3 Feb 2022 21:05:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
>> replicate().
>> 
>> I was not able to reproduce the reported failure using:
>> 
>>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
>> 
>> so I'm moving forward with the proposed fix from a code inspection
>> point of view.
>> 
>> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
>> no failures. Tier[3-6] are still running.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kimbarrett and adinn CR changes

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7270

From stuefe at openjdk.java.net  Fri Feb  4 05:32:50 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 05:32:50 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v2]
In-Reply-To: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
Message-ID: <l70LYhh2oqauHCa5hTQli9U1dFHs6PDSO9pckLzkOsU=.c07d4432-2e64-4df4-bcbc-8ae41dfa3bed@github.com>

> release_multi_mappings_vm is unfortunately racy.
> 
> The original intention of the test was to check that `os::release_memory()` works across multiple mappings allocated with multiple calls to `os::reserve_memory()`. This was broken for a long time on windows, since it relies on the implicit assumption that every platform uses mmap-ish APIs under the hood. But Windows virtual memory API (and SysV shmat, for that matter) does not work that way.
> 
> The release_multi_mappings_vm test 
> - A reserves a number of mappings in 4M stripes adjacent to each other 
> - B releases them with a single call to os::release_memory
> - C re-allocates a range at the same address
> 
> Step (C) will fail if the os::release call in (B) failed to release the mapping. Which it sometimes did silently, so just checking the return code in (B) was not sufficient.
> 
> Unfortunately, it will also fail if someone concurrently mapped into the range between (B) and (C). It's rare, but it happens.
> 
> This is difficult to make completely airtight, but we could make it much more stable:
> 1) instead of releasing all stripes, just release the n middle stripes (n>1) and leave first and last stripe reserved. Then, in (C), re-reserve the middle stripes. Tests the same (as long as we have multiple middle stripes) but drastically decreases the chance of some random allocation placing memory into the vacated address hole
> 2) reduce the stripe size from today's 4M to something much smaller. Again, reduces the chance of stray mappings being placed into the hole since it will be smaller too.
> 
> The patch does just that.
> It also adds a lengthy comment.
> I also needed to place the NUMASwitcher line in front of the last os::release_memory. That is done just  to clean up everything before the tests ends, but now its a multi-mapping-release too (we now release front stripe, middle, and end stripe).
> 
> Tests:
> - GHAs
> - manually ran the test on x64 Linux
> - SAP nightlies

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

  Dans remarks

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7288/files
  - new: https://git.openjdk.java.net/jdk/pull/7288/files/36bcff1e..f6014cc5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7288&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7288&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From stuefe at openjdk.java.net  Fri Feb  4 05:32:51 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 05:32:51 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v2]
In-Reply-To: <wmj_Mj80-HfOJSMSvHmNFOO_LiP-hjRqu7G5-fZPz-o=.330fa604-25b1-4c5c-ab65-7f01eedd17df@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <wmj_Mj80-HfOJSMSvHmNFOO_LiP-hjRqu7G5-fZPz-o=.330fa604-25b1-4c5c-ab65-7f01eedd17df@github.com>
Message-ID: <tZUnrbKfec6iE3DK8RsfM4eyiqLgnOSSfdvDb-s-xmU=.c1f4b086-26b3-4c6f-b51c-a5ecd0cadd58@github.com>

On Thu, 3 Feb 2022 20:33:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dans remarks
>
> Thumbs up.
> 
> You may want to correct 'NUMASwitchter' in the PR so that
> any searches find the correct name.

Thanks @dcubed-ojdk !

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From iklam at openjdk.java.net  Fri Feb  4 06:56:06 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 4 Feb 2022 06:56:06 GMT
Subject: RFR: 8280767: -XX:ArchiveClassesAtExit does not archive
 BoundMethodHandle$Species classes [v2]
In-Reply-To: <zVW-nr_7Lfr2stFYg_g1f_mqtCwBqt0EiW8nj_zYKP4=.0719db9b-6f10-4b67-9671-3389827d9861@github.com>
References: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
 <zVW-nr_7Lfr2stFYg_g1f_mqtCwBqt0EiW8nj_zYKP4=.0719db9b-6f10-4b67-9671-3389827d9861@github.com>
Message-ID: <TA9n-Hf1fWF9jll3KB9-tvALC4Dtr0tGmcmlML5LVzc=.676dbea7-87da-41fb-8e26-d0e43d8fa7b2@github.com>

On Thu, 3 Feb 2022 22:26:57 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   When do dynamic dump, the call to LambdaForInvolkers::append_filtered for generating lambda holder classes will only allow the result which matches the filtering list to be added . This filters out the SPECIES method handle holder classes, and they won't be archived in dynamic shared archive. The patch is doing followings:
>>   1) Removed the call to  LambdaForInvolkers::append_filtered, instead just call LambdaForInvolkers::append so the SPECIES can be added to the regeneration list.
>>   2) Added an enum for  shared flag in Klass, _generated to indicate the class is regenerated and it should not be loaded from CDS if CFLH is enabled. If the class is a SPECIES and also loaded from base archive, skip regenerating it for dynamic archive.
>>   3) If CFLH is enabled, for regenerated classes, avoid calling CFLH.
>> 
>> Tests: tier1,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid call CFLH for regenerated lambda holder classes, reversed change for is_hidden_lambda_proxy

LGTM. A small nit on the comments.

src/hotspot/share/classfile/systemDictionaryShared.cpp line 1418:

> 1416:     assert(!record->_klass->is_hidden(), "hidden class cannot be looked up by name");
> 1417:     assert(check_alignment(record->_klass), "Address not aligned");
> 1418:     // The regenerated lamdbda Holder classes are not saved, should avoid call CFLH

I think it will be clear to say

// We did not save the classfile data of the regenerated LambdaForm invoker classes,
// so we cannot support CLFH for such classes.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7329

From mdoerr at openjdk.java.net  Fri Feb  4 09:30:21 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 4 Feb 2022 09:30:21 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
Message-ID: <XDrx2Bd8_q11_t3iKi_AWP2yLL3TNZ8304Cb_yQPIDM=.7000e977-7215-479f-a601-0c63b6d15b63@github.com>

On Fri, 4 Feb 2022 00:25:43 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Adding IBM Copyright may be appropriate in files in which you have made significant contributions.
If you add Oracle Copyright lines, please make sure to do it correctly (not "2022, 2022").
Note that your former colleagues haven't done any of that in most cases. I can't tell if this should be done and I think the change can get integrated as it is.
There's no answer, yet: https://mail.openjdk.java.net/pipermail/jdk-dev/2022-January/006364.html

> I'm a fan of more testing @tstuefe. Let me know if you discover anything interesting.

Testing is hard for us because we don't have nightly builds and tests on AIX any more. I don't know if he can afford doing much for it.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From aph at openjdk.java.net  Fri Feb  4 10:05:07 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 4 Feb 2022 10:05:07 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
 <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>
Message-ID: <0N9FxechUMfug8q0sB98JSxgfCP_y6Amz2Y9HtaoPWw=.68c7df06-26ac-493a-84e2-4e6e65068f5f@github.com>

On Thu, 3 Feb 2022 17:21:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> It's definitely UB according to the language.  Then there's the question of what the hardware might actually implement in the cases where the compiler doesn't recognize it and the relevant instruction(s) are executed with that value.  I know I've seen hardware that used the shift quantity mod word-size.  I think I've seen hardware that would just shift out all the bits, leaving a value of 0.  One reason for the language to make this UB is because of hardware variance.  Oh, and I *think* I've seen hardware where it was UB and would produce "strange" results.
>
> @kimbarrett - Thanks for confirming that we have UB here.
> 
> @adinn - I'll take a look and updating the `assert()` calls and retest.

> First thing to note is that `replicate` is never actually called with `count == 0`.

This is crucial: it means we have no UB.

Could I ask you to take the opportunity add a little of this commentary to the rather opaque code? Pretty please? :-)

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From adinn at openjdk.java.net  Fri Feb  4 10:49:12 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Fri, 4 Feb 2022 10:49:12 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <0N9FxechUMfug8q0sB98JSxgfCP_y6Amz2Y9HtaoPWw=.68c7df06-26ac-493a-84e2-4e6e65068f5f@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
 <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>
 <0N9FxechUMfug8q0sB98JSxgfCP_y6Amz2Y9HtaoPWw=.68c7df06-26ac-493a-84e2-4e6e65068f5f@github.com>
Message-ID: <wl6KF6Ij9he0EH0CjeO3vloYEeEmrI-VRI4FgC4ahpI=.6b8c955d-8f04-44e2-9bb1-436856b1cf48@github.com>

On Fri, 4 Feb 2022 10:01:53 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Could I ask you to take the opportunity add a little of this commentary to the rather opaque code? Pretty please? :-)

Sure,this stuff really needs to be better documented in the code itself. I'll do that as a follow-up to this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From kbarrett at openjdk.java.net  Fri Feb  4 10:53:36 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Feb 2022 10:53:36 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
Message-ID: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>

[Trying again, after a couple previous proposals.]

Please review this change to os::pretouch_memory to permit use of the memory
being pretouched concurrently with the pretouch operation.  This will allow
future changes that can make use of such overlap.

Testing:
mach5 tier1-3 with -XX:+AlwaysPreTouch.

Verified no performance impact by comparing startup times with Epsilon GC and
-XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
significant amount of time.  Tested on both linux-x64 and linux-aarch64.

None of these test concurrent use; that will wait for future changes that use
the new feature.

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

Commit messages:
 - pretouch allowing concurrent access

Changes: https://git.openjdk.java.net/jdk/pull/7343/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7343&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272807
  Stats: 27 lines in 2 files changed: 17 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7343.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7343/head:pull/7343

PR: https://git.openjdk.java.net/jdk/pull/7343

From shade at openjdk.java.net  Fri Feb  4 11:11:05 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Feb 2022 11:11:05 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
Message-ID: <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>

On Fri, 4 Feb 2022 10:47:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> [Trying again, after a couple previous proposals.]
> 
> Please review this change to os::pretouch_memory to permit use of the memory
> being pretouched concurrently with the pretouch operation.  This will allow
> future changes that can make use of such overlap.
> 
> Testing:
> mach5 tier1-3 with -XX:+AlwaysPreTouch.
> 
> Verified no performance impact by comparing startup times with Epsilon GC and
> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
> 
> None of these test concurrent use; that will wait for future changes that use
> the new feature.

Looks okay to me, with minor nits.

src/hotspot/share/runtime/os.cpp line 1758:

> 1756: void os::pretouch_memory(void* start, void* end, size_t page_size) {
> 1757:   assert(is_power_of_2(page_size), "page size misaligned: %zu", page_size);
> 1758:   assert(page_size >= sizeof(int), "page size too small: %zu", page_size);

`SIZE_FORMAT` instead of `%zu`.

src/hotspot/share/runtime/os.cpp line 1771:

> 1769:       Atomic::add(reinterpret_cast<int*>(cur), 0, memory_order_relaxed);
> 1770:       if (cur == last) break;
> 1771:     }

Took me some time to check the loop. Suggestion:


    do {
      Atomic::add(reinterpret_cast<int*>(cur), 0, memory_order_relaxed);
      cur += page_size;
    } while (cur < last);

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From duke at openjdk.java.net  Fri Feb  4 11:35:55 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Fri, 4 Feb 2022 11:35:55 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <5ouvmH_2BZBIe4WAs-lZs5iYCBZdJZ3EEb373ZLWvyE=.9eda05f7-f588-40e2-9daa-e962c75cf3fb@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: Review comments resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/cb29b832..91ab8255

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=00-01

  Stats: 26 lines in 3 files changed: 2 ins; 11 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Fri Feb  4 11:39:11 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Fri, 4 Feb 2022 11:39:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
In-Reply-To: <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
Message-ID: <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>

On Thu, 3 Feb 2022 16:48:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8271195: Review comments resolved.
>
> src/hotspot/os/linux/os_linux.cpp line 4038:
> 
>> 4036:   if (!large_committed) {
>> 4037:     // Failed to commit large pages, so we need to unmap the whole reservation.
>> 4038:     ::munmap(aligned_start, bytes);
> 
> I don't understand why this change is related to this ticket/PR, or needed at all.

As mentioned above in case of large page commit failure we were partially un reserving the memory which left holes in the virtual address space , we thought of fixing this along with this patch if you suggest we can fix it under another bug id.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From ayang at openjdk.java.net  Fri Feb  4 12:10:06 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 12:10:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
In-Reply-To: <5ouvmH_2BZBIe4WAs-lZs5iYCBZdJZ3EEb373ZLWvyE=.9eda05f7-f588-40e2-9daa-e962c75cf3fb@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <5ouvmH_2BZBIe4WAs-lZs5iYCBZdJZ3EEb373ZLWvyE=.9eda05f7-f588-40e2-9daa-e962c75cf3fb@github.com>
Message-ID: <9h0_vx3Mn_PMX-SuFHD1wG6NgSt__O1Le6wbD26IloU=.99255c43-c294-4eb1-af5e-b935cf6425aa@github.com>

On Fri, 4 Feb 2022 11:35:55 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

Thank you for the revision; some further comments/suggestions.

src/hotspot/os/linux/os_linux.cpp line 3497:

> 3495: bool os::Linux::hugetlbfs_sanity_check(bool warn, size_t page_size) {
> 3496:    bool large_page_found = false;
> 3497:   // Include the page size flag to ensure we sanity check the correct page size.

This comment should be moved.

src/hotspot/os/linux/os_linux.cpp line 3501:

> 3499:     if (os::Linux::try_commit_using_large_page(local_page_size) && !large_page_found) {
> 3500:       _large_page_size = local_page_size;
> 3501:       large_page_found = true;

I think one can use early-return here, which removes `large_page_found` and the `if (warn)` below is skipped automatically.

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

Changes requested by ayang (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7326

From ayang at openjdk.java.net  Fri Feb  4 12:10:06 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 12:10:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
In-Reply-To: <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
Message-ID: <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>

On Fri, 4 Feb 2022 11:35:56 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> which left holes in the virtual address space

That sounds like virtual address leaking; should be dealt with in its own ticket/PR.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From kbarrett at openjdk.java.net  Fri Feb  4 12:11:10 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Feb 2022 12:11:10 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
Message-ID: <MQejfQ16EQzKJp_4IiGts298qdKN4Ml2j3kaWBvG1q8=.7428c11c-5ead-4aac-b378-51f8e54b9855@github.com>

On Fri, 4 Feb 2022 11:07:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [Trying again, after a couple previous proposals.]
>> 
>> Please review this change to os::pretouch_memory to permit use of the memory
>> being pretouched concurrently with the pretouch operation.  This will allow
>> future changes that can make use of such overlap.
>> 
>> Testing:
>> mach5 tier1-3 with -XX:+AlwaysPreTouch.
>> 
>> Verified no performance impact by comparing startup times with Epsilon GC and
>> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
>> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
>> 
>> None of these test concurrent use; that will wait for future changes that use
>> the new feature.
>
> src/hotspot/share/runtime/os.cpp line 1771:
> 
>> 1769:       Atomic::add(reinterpret_cast<int*>(cur), 0, memory_order_relaxed);
>> 1770:       if (cur == last) break;
>> 1771:     }
> 
> Took me some time to check the loop. Suggestion:
> 
> 
>     do {
>       Atomic::add(reinterpret_cast<int*>(cur), 0, memory_order_relaxed);
>       cur += page_size;
>     } while (cur < last);

Intentionally didn't write it that way, because of the potential for UB pointer arithmetic overflow in `cur += page_size`.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From jbhateja at openjdk.java.net  Fri Feb  4 12:23:12 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 4 Feb 2022 12:23:12 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
In-Reply-To: <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
Message-ID: <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>

On Fri, 4 Feb 2022 11:57:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> As mentioned above in case of large page commit failure we were partially un reserving the memory which left holes in the virtual address space , we thought of fixing this along with this patch if you suggest we can fix it under another bug id.
>
>> which left holes in the virtual address space
> 
> That sounds like virtual address leaking; should be dealt with in its own ticket/PR.

New ticket created:
https://bugs.openjdk.java.net/browse/JDK-8281263

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From kbarrett at openjdk.java.net  Fri Feb  4 12:25:10 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Feb 2022 12:25:10 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
Message-ID: <YVNt0R6GJGimyqjAH_urHUGX4ndWm3z0VRR1uzQLxgI=.3b3acfde-c349-4b79-ab8b-d6aea7231939@github.com>

On Fri, 4 Feb 2022 11:05:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [Trying again, after a couple previous proposals.]
>> 
>> Please review this change to os::pretouch_memory to permit use of the memory
>> being pretouched concurrently with the pretouch operation.  This will allow
>> future changes that can make use of such overlap.
>> 
>> Testing:
>> mach5 tier1-3 with -XX:+AlwaysPreTouch.
>> 
>> Verified no performance impact by comparing startup times with Epsilon GC and
>> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
>> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
>> 
>> None of these test concurrent use; that will wait for future changes that use
>> the new feature.
>
> src/hotspot/share/runtime/os.cpp line 1758:
> 
>> 1756: void os::pretouch_memory(void* start, void* end, size_t page_size) {
>> 1757:   assert(is_power_of_2(page_size), "page size misaligned: %zu", page_size);
>> 1758:   assert(page_size >= sizeof(int), "page size too small: %zu", page_size);
> 
> `SIZE_FORMAT` instead of `%zu`.

`%zu` is C99 Standard, so also available in C++14.  It's also long been supported by gcc in C++03 mode, and by at least VS2015 and later. See https://bugs.openjdk.java.net/browse/JDK-8256379.  There's been no effort to go back and change existing code, but it's been getting used in new code for a while.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From stuefe at openjdk.java.net  Fri Feb  4 12:31:08 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 12:31:08 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
Message-ID: <pfukF3o5X_EvqstPpfaWC-G_VLmJP_EPy9szPVqWk6Q=.3431ff7d-17cc-4c6e-9cb8-ae86ad77254e@github.com>

On Fri, 4 Feb 2022 10:47:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> [Trying again, after a couple previous proposals.]
> 
> Please review this change to os::pretouch_memory to permit use of the memory
> being pretouched concurrently with the pretouch operation.  This will allow
> future changes that can make use of such overlap.
> 
> Testing:
> mach5 tier1-3 with -XX:+AlwaysPreTouch.
> 
> Verified no performance impact by comparing startup times with Epsilon GC and
> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
> 
> None of these test concurrent use; that will wait for future changes that use
> the new feature.

Looks good.

I wondered for a moment if the underlying hardware could optimize something like `xadd mem, r=0` out. Since the effect would not be observable. But it would have to at least return the old memory content. It's probably fine.

A gtest would be nice, but probably difficult to write in a way to reliably show errors without this patch.

src/hotspot/share/runtime/os.cpp line 1759:

> 1757:   assert(is_power_of_2(page_size), "page size misaligned: %zu", page_size);
> 1758:   assert(page_size >= sizeof(int), "page size too small: %zu", page_size);
> 1759:   if (start < end) {

Should we assert start <= end, or maybe even start < end?

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7343

From stuefe at openjdk.java.net  Fri Feb  4 12:31:09 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 12:31:09 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <YVNt0R6GJGimyqjAH_urHUGX4ndWm3z0VRR1uzQLxgI=.3b3acfde-c349-4b79-ab8b-d6aea7231939@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
 <YVNt0R6GJGimyqjAH_urHUGX4ndWm3z0VRR1uzQLxgI=.3b3acfde-c349-4b79-ab8b-d6aea7231939@github.com>
Message-ID: <_ZRr5Wf-MJff1Uifn_9UIBM_CXPu0IiCoO7IKo-UkXc=.884e3dac-0dc4-43e0-a142-7613dbe6e16a@github.com>

On Fri, 4 Feb 2022 12:21:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.cpp line 1758:
>> 
>>> 1756: void os::pretouch_memory(void* start, void* end, size_t page_size) {
>>> 1757:   assert(is_power_of_2(page_size), "page size misaligned: %zu", page_size);
>>> 1758:   assert(page_size >= sizeof(int), "page size too small: %zu", page_size);
>> 
>> `SIZE_FORMAT` instead of `%zu`.
>
> `%zu` is C99 Standard, so also available in C++14.  It's also long been supported by gcc in C++03 mode, and by at least VS2015 and later. See https://bugs.openjdk.java.net/browse/JDK-8256379.  There's been no effort to go back and change existing code, but it's been getting used in new code for a while.

So, do you use that also for UINTX_FORMAT?

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From kbarrett at openjdk.java.net  Fri Feb  4 12:34:04 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Feb 2022 12:34:04 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <MQejfQ16EQzKJp_4IiGts298qdKN4Ml2j3kaWBvG1q8=.7428c11c-5ead-4aac-b378-51f8e54b9855@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
 <MQejfQ16EQzKJp_4IiGts298qdKN4Ml2j3kaWBvG1q8=.7428c11c-5ead-4aac-b378-51f8e54b9855@github.com>
Message-ID: <_02hc_OAvXGm0I9gsBw3OCHVnL9xx3B0CJyjzH5v82U=.86b2e230-1ceb-4592-86db-6786b4a35e41@github.com>

On Fri, 4 Feb 2022 12:07:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.cpp line 1771:
>> 
>>> 1769:       Atomic::add(reinterpret_cast<int*>(cur), 0, memory_order_relaxed);
>>> 1770:       if (cur == last) break;
>>> 1771:     }
>> 
>> Took me some time to check the loop. Suggestion:
>> 
>> 
>>     do {
>>       Atomic::add(reinterpret_cast<int*>(cur), 0, memory_order_relaxed);
>>       cur += page_size;
>>     } while (cur < last);
>
> Intentionally didn't write it that way, because of the potential for UB pointer arithmetic overflow in `cur += page_size`.

Also, that won't touch the last page when first page != last page, unless the last page is made exclusive, which calculation could also suffer from UB pointer arithmetic overflow.  Of course, the caller could suffer from that too; we can't so easily fix that.  Representing address ranges as [start, end) just generally suffers from that problem.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From kbarrett at openjdk.java.net  Fri Feb  4 12:40:12 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Feb 2022 12:40:12 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <pfukF3o5X_EvqstPpfaWC-G_VLmJP_EPy9szPVqWk6Q=.3431ff7d-17cc-4c6e-9cb8-ae86ad77254e@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <pfukF3o5X_EvqstPpfaWC-G_VLmJP_EPy9szPVqWk6Q=.3431ff7d-17cc-4c6e-9cb8-ae86ad77254e@github.com>
Message-ID: <h2KCLYJLW05rwFz95dr6ynnTjWRsh5SvKb8CdaIndUc=.041eb72c-e0a5-42ab-b2f1-1805afb5f780@github.com>

On Fri, 4 Feb 2022 12:18:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> [Trying again, after a couple previous proposals.]
>> 
>> Please review this change to os::pretouch_memory to permit use of the memory
>> being pretouched concurrently with the pretouch operation.  This will allow
>> future changes that can make use of such overlap.
>> 
>> Testing:
>> mach5 tier1-3 with -XX:+AlwaysPreTouch.
>> 
>> Verified no performance impact by comparing startup times with Epsilon GC and
>> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
>> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
>> 
>> None of these test concurrent use; that will wait for future changes that use
>> the new feature.
>
> src/hotspot/share/runtime/os.cpp line 1759:
> 
>> 1757:   assert(is_power_of_2(page_size), "page size misaligned: %zu", page_size);
>> 1758:   assert(page_size >= sizeof(int), "page size too small: %zu", page_size);
>> 1759:   if (start < end) {
> 
> Should we assert start <= end, or maybe even start < end?

I waffled over asserting start <= end, so have no objection to making that change.  In testing I ran across cases of start == end, though haven't pursued them to see if they might indicate a problem or just a reasonable boundary case.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From duke at openjdk.java.net  Fri Feb  4 12:50:49 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Fri, 4 Feb 2022 12:50:49 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: Review comments resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/91ab8255..fadcb5b9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=01-02

  Stats: 12 lines in 1 file changed: 3 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From kbarrett at openjdk.java.net  Fri Feb  4 13:11:13 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Feb 2022 13:11:13 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <_ZRr5Wf-MJff1Uifn_9UIBM_CXPu0IiCoO7IKo-UkXc=.884e3dac-0dc4-43e0-a142-7613dbe6e16a@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
 <YVNt0R6GJGimyqjAH_urHUGX4ndWm3z0VRR1uzQLxgI=.3b3acfde-c349-4b79-ab8b-d6aea7231939@github.com>
 <_ZRr5Wf-MJff1Uifn_9UIBM_CXPu0IiCoO7IKo-UkXc=.884e3dac-0dc4-43e0-a142-7613dbe6e16a@github.com>
Message-ID: <82WACKaQqn2k4XPZKf50cHTTJsdwW5dqGpZhRQdYS6k=.caa9709b-5e7a-4853-833d-76f25c790c88@github.com>

On Fri, 4 Feb 2022 12:27:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> `%zu` is C99 Standard, so also available in C++14.  It's also long been supported by gcc in C++03 mode, and by at least VS2015 and later. See https://bugs.openjdk.java.net/browse/JDK-8256379.  There's been no effort to go back and change existing code, but it's been getting used in new code for a while.
>
> So, do you use that also for UINTX_FORMAT?

I can't recall the last time I needed to use `INTX_FORMAT` or `UINTX_FORMAT` and had kind of forgotten about them.  But yes, those seem similarly replaceable.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From ayang at openjdk.java.net  Fri Feb  4 13:33:11 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 13:33:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <0gWuDe6CyHrJonoeEgLjWAh_QfjZBn15zH4-vhfMzTA=.cc325724-239f-4a84-a43f-17df843bb7b9@github.com>

On Fri, 4 Feb 2022 12:50:49 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

Two small and subjective suggestions:

1. `try_commit_using_large_page` can be dropped from the header (API), (i.e. change to a file-local function, `static bool try_commit_using_large_page(...) {...}`.
2. Placing `log_info` inside `hugetlbfs_sanity_check` feels cleaner (the assignment is next to the msg), sth like:


if (try_commit_using_large_page...) {
  _large_page_size = ...
  log_info(... success ...);
  return true;
}
log_info(... fail ...);


I don't see much benefit of adding `MicroLargePages.java`. Would be nice if someone more experience on this can share their opinions.

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

Marked as reviewed by ayang (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Fri Feb  4 13:37:32 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Fri, 4 Feb 2022 13:37:32 GMT
Subject: RFR: 8281263: virtual space leakage if large page commit fails.
Message-ID: <GB2yuKxKcQHngEo432Y-6ETH6bfaSAV_2sONpdgiaPY=.f4ec78a2-47cb-4503-9ef2-b9311890a145@github.com>

Hi Team,

In this patch I have fixed the virtual space leakage issue. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.

Please review and provide your valuable comments.


Thanks,
Swati Sharma
Runtime Software Development Engineer 
Intel

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

Commit messages:
 - 8281263: virtual space leakage if large page commit fails.

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

PR: https://git.openjdk.java.net/jdk/pull/7350

From sjohanss at openjdk.java.net  Fri Feb  4 15:11:12 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 4 Feb 2022 15:11:12 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
Message-ID: <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>

On Fri, 4 Feb 2022 12:20:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> which left holes in the virtual address space
>> 
>> That sounds like virtual address leaking; should be dealt with in its own ticket/PR.
>
> New ticket created:
> https://bugs.openjdk.java.net/browse/JDK-8281263

The documentation around `mmap` with MAP_FIXED is not crystal clear on failure. In the case we return false from `commit_memory_special(...)` the commit over the reserved range failed and I'm pretty sure that when it does the virtual memory range reserved becomes available to the system again and might be reused by some other thread. So unmapping that range would break any such reservation. @stefank isn't this what we've had problems with in the past?

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From stuefe at openjdk.java.net  Fri Feb  4 15:28:07 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:28:07 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>

On Fri, 4 Feb 2022 12:50:49 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

Hi @swati-sha,

What tests have you run, and on what hardware?

It would be nice if @kstefanj could take a look at this.

> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.

This text (and the description in the associated JBS issue) are a bit confusing. What should be the desired behavior of LargePageSizeInBytes wrt to heap allocation?

Currently, the behavior is different between code cache and heap: 
1) For code cache `LargePageSizeInBytes` means the largest possible page size to use, with the explicit permission to use smaller ones where available. 
2) For the heap, `LargePageSizeInBytes` means "use that or no large pages at all".
Both behaviors could make sense. (2) could make sense if the administrator set up a 2M pool for some other program and now it gets gnawed at by the JVM. Though admittedly that seems contrived. "Use that or fail" would make more sense.

Unfortunately, the java man page is no help:


LargePageSizeInBytes
Sets the maximum large page size (in bytes) used by the JVM.


... could mean either 1 or 2.

The code cache side we had extensively discussed when reviewing https://bugs.openjdk.java.net/browse/JDK-8256155. 

> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.

This part of the PR text is confusing. I do not find this in the patch. Does the text match the code? Note that it would make sense in a separate bug fix.

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From stefank at openjdk.java.net  Fri Feb  4 15:28:08 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 4 Feb 2022 15:28:08 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
Message-ID: <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>

On Fri, 4 Feb 2022 15:07:54 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> New ticket created:
>> https://bugs.openjdk.java.net/browse/JDK-8281263
>
> The documentation around `mmap` with MAP_FIXED is not crystal clear on failure. In the case we return false from `commit_memory_special(...)` the commit over the reserved range failed and I'm pretty sure that when it does the virtual memory range reserved becomes available to the system again and might be reused by some other thread. So unmapping that range would break any such reservation. @stefank isn't this what we've had problems with in the past?

Yes, that is my understanding.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From stefank at openjdk.java.net  Fri Feb  4 15:36:11 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 4 Feb 2022 15:36:11 GMT
Subject: RFR: 8281263: virtual space leakage if large page commit fails.
In-Reply-To: <GB2yuKxKcQHngEo432Y-6ETH6bfaSAV_2sONpdgiaPY=.f4ec78a2-47cb-4503-9ef2-b9311890a145@github.com>
References: <GB2yuKxKcQHngEo432Y-6ETH6bfaSAV_2sONpdgiaPY=.f4ec78a2-47cb-4503-9ef2-b9311890a145@github.com>
Message-ID: <6ytQQEsvUpLMxXUUl75XXZpM4rodTgfPLABAhLOzf3M=.359b354e-288f-4220-a14e-530488bb6669@github.com>

On Fri, 4 Feb 2022 13:27:58 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Hi Team,
> 
> In this patch I have fixed the virtual space leakage issue. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> Please review and provide your valuable comments.
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

I'm not convinced that this is needed or even safe. My understanding is that you have already lost the reservation [aligned_start, aligned_start + large_bytes) when the large page commit failed. If that is the case, then it is unsafe to unmap it again, since another thread could race and reserve that memory, and then this thread would potentially unmap the other thread's memory.

Could you provide some data help me understand the problem you are seeing?

I'd like to see the values of aligned_start, large_bytes and bytes and a preferably a dump of /proc/<pid>/maps when  the coded enters the if statement:

if (!large_committed) {
    // Failed to commit large pages, so we need to unmap the

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

Changes requested by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7350

From stuefe at openjdk.java.net  Fri Feb  4 15:37:23 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:37:23 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <QyrvbOGAcOvJnAQIColOCMsNTRx86MlYoaK-uVjCOcs=.ef595e77-5380-44d2-a06b-e43e7786509d@github.com>

On Fri, 4 Feb 2022 12:50:49 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

BTW, if we want to implement a fluid fallback to smaller large page sizes, I am not sure we want to rely on a test done during VM initialization. The VM could wish to reserve+commit large pages at any point later, and the state of the huge page pool may be different then from when the VM started.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From ayang at openjdk.java.net  Fri Feb  4 15:41:08 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 15:41:08 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
Message-ID: <E1JfaIjErYy3Mn5igm-cta4E7N_H32BCT2EdMS4omrQ=.b3ff7b89-5cec-4a66-8737-08e9d951777c@github.com>

On Fri, 4 Feb 2022 15:24:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For the heap, LargePageSizeInBytes means "use that or no large pages at all".

@tstuefe, with https://bugs.openjdk.java.net/browse/JDK-8265517, such flag has the same semantic for code cache and heap.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From minqi at openjdk.java.net  Fri Feb  4 15:44:47 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 4 Feb 2022 15:44:47 GMT
Subject: RFR: 8280767: -XX:ArchiveClassesAtExit does not archive
 BoundMethodHandle$Species classes [v3]
In-Reply-To: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
References: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
Message-ID: <ac5NA3KMxRqjaToAgvBMptE-iq8leuEbpuIIO-VJi-Y=.7f654c18-6538-4cb3-9719-687ce181b728@github.com>

> Hi, Please review
> 
>   When do dynamic dump, the call to LambdaForInvolkers::append_filtered for generating lambda holder classes will only allow the result which matches the filtering list to be added . This filters out the SPECIES method handle holder classes, and they won't be archived in dynamic shared archive. The patch is doing followings:
>   1) Removed the call to  LambdaForInvolkers::append_filtered, instead just call LambdaForInvolkers::append so the SPECIES can be added to the regeneration list.
>   2) Added an enum for  shared flag in Klass, _generated to indicate the class is regenerated and it should not be loaded from CDS if CFLH is enabled. If the class is a SPECIES and also loaded from base archive, skip regenerating it for dynamic archive.
>   3) If CFLH is enabled, for regenerated classes, avoid calling CFLH.
> 
> Tests: tier1,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Fixed comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7329/files
  - new: https://git.openjdk.java.net/jdk/pull/7329/files/8f1d356c..1ef457d6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7329&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7329&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7329

From stuefe at openjdk.java.net  Fri Feb  4 15:45:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:45:15 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
Message-ID: <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>

On Fri, 4 Feb 2022 15:22:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The documentation around `mmap` with MAP_FIXED is not crystal clear on failure. In the case we return false from `commit_memory_special(...)` the commit over the reserved range failed and I'm pretty sure that when it does the virtual memory range reserved becomes available to the system again and might be reused by some other thread. So unmapping that range would break any such reservation. @stefank isn't this what we've had problems with in the past?
>
> Yes, that is my understanding.

I believe it was https://bugs.openjdk.java.net/browse/JDK-8007074. Wasn't that the reason that large page memory on Linux gets committed right away when reserving?

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From stuefe at openjdk.java.net  Fri Feb  4 15:51:10 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:51:10 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <E1JfaIjErYy3Mn5igm-cta4E7N_H32BCT2EdMS4omrQ=.b3ff7b89-5cec-4a66-8737-08e9d951777c@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
 <E1JfaIjErYy3Mn5igm-cta4E7N_H32BCT2EdMS4omrQ=.b3ff7b89-5cec-4a66-8737-08e9d951777c@github.com>
Message-ID: <-GSxZS2hPzJPshDBM_q4ut0ArzIUVDLJZb5hZc1G-nE=.93a4e6d8-16dd-4509-b1ea-d02aaad683ec@github.com>

On Fri, 4 Feb 2022 15:37:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > For the heap, LargePageSizeInBytes means "use that or no large pages at all".
> 
> @tstuefe, with https://bugs.openjdk.java.net/browse/JDK-8265517, such flag has the same semantic for code cache and heap.

Thank you @albertnetymk! I now remember this again. So the rule is the JVM is free to use whatever large pages it finds, up to and including LargePageSizeInBytes. Okay, then this patch makes sense.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From stuefe at openjdk.java.net  Fri Feb  4 15:51:11 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:51:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
Message-ID: <l5CA6f_vm5xos_4BWSVC_yO3sE5zhZMTe460TwM3bog=.b394e5a7-3603-42a9-8916-63d638202e65@github.com>

On Fri, 4 Feb 2022 15:24:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This part of the PR text is confusing. I do not find this in the patch. Does the text match the code? Note that it would make sense in a separate bug fix.

My fault, I see from the PR discussion that this part moved to https://bugs.openjdk.java.net/browse/JDK-8281263. Could you please update the PR text?

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From stefank at openjdk.java.net  Fri Feb  4 15:51:11 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 4 Feb 2022 15:51:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
 <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
Message-ID: <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>

On Fri, 4 Feb 2022 15:41:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yes, that is my understanding.
>
> I believe it was https://bugs.openjdk.java.net/browse/JDK-8007074. Wasn't that the reason that large page memory on Linux gets committed right away when reserving?

Yes, it was.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From stuefe at openjdk.java.net  Fri Feb  4 15:56:11 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:56:11 GMT
Subject: RFR: 8281263: virtual space leakage if large page commit fails.
In-Reply-To: <6ytQQEsvUpLMxXUUl75XXZpM4rodTgfPLABAhLOzf3M=.359b354e-288f-4220-a14e-530488bb6669@github.com>
References: <GB2yuKxKcQHngEo432Y-6ETH6bfaSAV_2sONpdgiaPY=.f4ec78a2-47cb-4503-9ef2-b9311890a145@github.com>
 <6ytQQEsvUpLMxXUUl75XXZpM4rodTgfPLABAhLOzf3M=.359b354e-288f-4220-a14e-530488bb6669@github.com>
Message-ID: <xWTJRWg9tgxBfFCm6nkQ74GquLNBtNJvvTeKUwve6Bc=.bab55dfb-ce22-4807-a410-d1b464be57fc@github.com>

On Fri, 4 Feb 2022 15:32:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I'm not convinced that this is needed or even safe. My understanding is that you have already lost the reservation [aligned_start, aligned_start + large_bytes) when the large page commit failed. If that is the case, then it is unsafe to unmap it again, since another thread could race and reserve that memory, and then this thread would potentially unmap the other thread's memory.

I thought so too. See also https://bugs.openjdk.java.net/browse/JDK-8007074, which was caused by a failing commit leaving the address range in question unmapped and available for concurrent reservations.

> 
> Could you provide some data help me understand the problem you are seeing?
> 
> I'd like to see the values of aligned_start, large_bytes and bytes and a preferably a dump of `/proc/<pid>/maps` when the coded enters the if statement:
> 
> ```
> if (!large_committed) {
>     // Failed to commit large pages, so we need to unmap the
> ```

Note that an easy way to get this would be to just assert at that point, the hs-err file should contain a copy of the maps file.

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

PR: https://git.openjdk.java.net/jdk/pull/7350

From duke at openjdk.java.net  Fri Feb  4 16:08:23 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Feb 2022 16:08:23 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
Message-ID: <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>

On Fri, 4 Feb 2022 00:25:43 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

I like the idea of adding the IBM copyright line more judiciously, and only when the changes I've made are significant. ProblemList.txt, where I've made a single line change, stands out in my mind as an example of where this line could be removed.

I don't believe there are any files which contain the Oracle "2022, 2022" copyright header anymore. Did you see any I'm missing @TheRealMDoerr?

Regarding testing: I have been regularly building and testing on my AIX 7.1 dev machine. In addition, I have run tier1 tests when the changes I'm making are complete. The only tier1 failures I observe are also failing on the master branch. I'm happy for a second tester if either of you feel it's warranted, but I don't feel it is a necessity.

---

I'll sit tight for a response from Iris before proceeding.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From dcubed at openjdk.java.net  Fri Feb  4 16:16:09 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Feb 2022 16:16:09 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v2]
In-Reply-To: <l70LYhh2oqauHCa5hTQli9U1dFHs6PDSO9pckLzkOsU=.c07d4432-2e64-4df4-bcbc-8ae41dfa3bed@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <l70LYhh2oqauHCa5hTQli9U1dFHs6PDSO9pckLzkOsU=.c07d4432-2e64-4df4-bcbc-8ae41dfa3bed@github.com>
Message-ID: <qddqAbpK1ixaiB9Uzpy7_Yds8ICqCje0Y6QDfGMfL-8=.6649cbb0-6c6f-45c9-9761-6ca4d1c90de0@github.com>

On Fri, 4 Feb 2022 05:32:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> release_multi_mappings_vm is unfortunately racy.
>> 
>> The original intention of the test was to check that `os::release_memory()` works across multiple mappings allocated with multiple calls to `os::reserve_memory()`. This was broken for a long time on windows, since it relies on the implicit assumption that every platform uses mmap-ish APIs under the hood. But Windows virtual memory API (and SysV shmat, for that matter) does not work that way.
>> 
>> The release_multi_mappings_vm test 
>> - A reserves a number of mappings in 4M stripes adjacent to each other 
>> - B releases them with a single call to os::release_memory
>> - C re-allocates a range at the same address
>> 
>> Step (C) will fail if the os::release call in (B) failed to release the mapping. Which it sometimes did silently, so just checking the return code in (B) was not sufficient.
>> 
>> Unfortunately, it will also fail if someone concurrently mapped into the range between (B) and (C). It's rare, but it happens.
>> 
>> This is difficult to make completely airtight, but we could make it much more stable:
>> 1) instead of releasing all stripes, just release the n middle stripes (n>1) and leave first and last stripe reserved. Then, in (C), re-reserve the middle stripes. Tests the same (as long as we have multiple middle stripes) but drastically decreases the chance of some random allocation placing memory into the vacated address hole
>> 2) reduce the stripe size from today's 4M to something much smaller. Again, reduces the chance of stray mappings being placed into the hole since it will be smaller too.
>> 
>> The patch does just that.
>> It also adds a lengthy comment.
>> I also needed to place the NUMASwitcher line in front of the last os::release_memory. That is done just  to clean up everything before the tests ends, but now its a multi-mapping-release too (we now release front stripe, middle, and end stripe).
>> 
>> Tests:
>> - GHAs
>> - manually ran the test on x64 Linux
>> - SAP nightlies
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dans remarks

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7288

From sjohanss at openjdk.java.net  Fri Feb  4 16:17:16 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 4 Feb 2022 16:17:16 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <6fgGHJm8ALeo5Wy8QKBibga_sHcCWnON9FHT2n6wAZA=.22a84a1e-cbad-46ff-af04-4c145af7bd9d@github.com>

On Fri, 4 Feb 2022 12:50:49 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

Hi @swati-sha and @tstuefe,

I was thinking the same thing, that you should see this PR :)

As mentioned this was discussed a lot in the review for [JDK-8256155](https://bugs.openjdk.java.net/browse/JDK-8256155). That said, I think there is room for improvement. What we settled on back then was that if any large page size passed the sanity check we consider large pages enabled. It can then of course look strange in some cases, but often when things are not working as expected it is because of some configuration "issue". 

I suspect that the problem you are running into is that the default large page size is 1G, but you only have 2M pages configured. The simple work-around for this issue would be to specify `-XX:LargePageSizeInBytes=2m` but it would of course be good if it worked out of the box. 

I did play around a bit trying to solve this, but it got shelved. I did try to solve it in the `ReservedSpace` layer instead. This would satisfy Thomas comment about not relying to much on checks at startup. I did something like: 


    diff --git a/src/hotspot/share/memory/virtualspace.cpp b/src/hotspot/share/memory/virtualspace.cpp
index c5f682bb31f..80d0910f150 100644
--- a/src/hotspot/share/memory/virtualspace.cpp
+++ b/src/hotspot/share/memory/virtualspace.cpp
@@ -235,11 +235,20 @@ void ReservedSpace::reserve(size_t size,
     // the caller requested large pages. To satisfy this request we use
     // explicit large pages and these have to be committed up front to ensure
     // no reservations are lost.
+    size_t used_page_size = page_size;
+    char* base = NULL;
+
+    do {
+      base = reserve_memory_special(requested_address, size, alignment, used_page_size, executable);
+      if (base != NULL) {
+        break;
+      }
+      used_page_size = os::page_sizes().next_smaller(used_page_size);
+    } while (used_page_size > (size_t) os::vm_page_size());
 
-    char* base = reserve_memory_special(requested_address, size, alignment, page_size, executable);
     if (base != NULL) {
       // Successful reservation using large pages.
-      initialize_members(base, size, alignment, page_size, true, executable);
+      initialize_members(base, size, alignment, used_page_size, true, executable);
       return;
     }
     // Failed to reserve explicit large pages, fall back to normal reservation.

This is completely untested, and there might be some other tweaks needed to make it work. What do you think about this kind of approach?

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From mdoerr at openjdk.java.net  Fri Feb  4 16:20:12 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 4 Feb 2022 16:20:12 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>
Message-ID: <N5geXLEn8vaODaHSwb-MqnngHDUgg1BAJMwB-iIx4Gk=.1641fafb-1721-4cd3-b781-36600db7760e@github.com>

On Fri, 4 Feb 2022 16:05:02 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> I like the idea of adding the IBM copyright line more judiciously, and only when the changes I've made are significant. ProblemList.txt, where I've made a single line change, stands out in my mind as an example of where this line could be removed.

Right. Please remove it where you didn't make significant contributions. Simple changes or even removals don't justify IBMs Copyright on the whole file. I don't think this is acceptable.

> I don't believe there are any files which contain the Oracle "2022, 2022" copyright header anymore. Did you see any I'm missing @TheRealMDoerr?

Seems like you fixed them already.

> Regarding testing: I have been regularly building and testing on my AIX 7.1 dev machine. In addition, I have run tier1 tests when the changes I'm making are complete. The only tier1 failures I observe are also failing on the master branch. I'm happy for a second tester if either of you feel it's warranted, but I don't feel it is a necessity.

That sounds good. There are not many people working on AIX. You may be alone. But, I'm glad you're doing it!

> I'll sit tight for a response from Iris before proceeding.

Be warned: This may take time. You certainly want your change to get integrated at some point of time.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From stefank at openjdk.java.net  Fri Feb  4 16:21:04 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 4 Feb 2022 16:21:04 GMT
Subject: RFR: 8281263: virtual space leakage if large page commit fails.
In-Reply-To: <xWTJRWg9tgxBfFCm6nkQ74GquLNBtNJvvTeKUwve6Bc=.bab55dfb-ce22-4807-a410-d1b464be57fc@github.com>
References: <GB2yuKxKcQHngEo432Y-6ETH6bfaSAV_2sONpdgiaPY=.f4ec78a2-47cb-4503-9ef2-b9311890a145@github.com>
 <6ytQQEsvUpLMxXUUl75XXZpM4rodTgfPLABAhLOzf3M=.359b354e-288f-4220-a14e-530488bb6669@github.com>
 <xWTJRWg9tgxBfFCm6nkQ74GquLNBtNJvvTeKUwve6Bc=.bab55dfb-ce22-4807-a410-d1b464be57fc@github.com>
Message-ID: <K7S8xWtdHOU11GE7yxyQKQbfh0Hg1vIEXnWyJHd_8zs=.8e300a96-5ead-4dab-b31a-ad4753ac262e@github.com>

On Fri, 4 Feb 2022 15:53:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I'm not convinced that this is needed or even safe. My understanding is that you have already lost the reservation [aligned_start, aligned_start + large_bytes) when the large page commit failed. If that is the case, then it is unsafe to unmap it again, since another thread could race and reserve that memory, and then this thread would potentially unmap the other thread's memory.
> 
> I thought so too. See also https://bugs.openjdk.java.net/browse/JDK-8007074, which was caused by a failing commit leaving the address range in question unmapped and available for concurrent reservations.
> 
> > Could you provide some data help me understand the problem you are seeing?
> > I'd like to see the values of aligned_start, large_bytes and bytes and a preferably a dump of `/proc/<pid>/maps` when the coded enters the if statement:
> > ```
> > if (!large_committed) {
> >     // Failed to commit large pages, so we need to unmap the
> > ```
> 
> Note that an easy way to get this would be to just assert at that point, the hs-err file should contain a copy of the maps file.

Great suggestion. I think something like would give us enough information:

assert(false, "Large pages commit failed " PTR_FORMAT " " PTR_FORMAT " " PTR_FORMAT, p2i(aligned_start), p2i(aligned_start + large_bytes), p2i(aligned_start + bytes));

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

PR: https://git.openjdk.java.net/jdk/pull/7350

From shade at openjdk.java.net  Fri Feb  4 16:21:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Feb 2022 16:21:06 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
Message-ID: <isT7xuSQpTMM05roRuj1HK9ssRb_-54VtVnMDbsdM_4=.ecab872f-d23f-45f3-96f6-9a3686fc76fd@github.com>

On Fri, 4 Feb 2022 10:47:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> [Trying again, after a couple previous proposals.]
> 
> Please review this change to os::pretouch_memory to permit use of the memory
> being pretouched concurrently with the pretouch operation.  This will allow
> future changes that can make use of such overlap.
> 
> Testing:
> mach5 tier1-3 with -XX:+AlwaysPreTouch.
> 
> Verified no performance impact by comparing startup times with Epsilon GC and
> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
> 
> None of these test concurrent use; that will wait for future changes that use
> the new feature.

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From shade at openjdk.java.net  Fri Feb  4 16:21:07 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Feb 2022 16:21:07 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <82WACKaQqn2k4XPZKf50cHTTJsdwW5dqGpZhRQdYS6k=.caa9709b-5e7a-4853-833d-76f25c790c88@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
 <YVNt0R6GJGimyqjAH_urHUGX4ndWm3z0VRR1uzQLxgI=.3b3acfde-c349-4b79-ab8b-d6aea7231939@github.com>
 <_ZRr5Wf-MJff1Uifn_9UIBM_CXPu0IiCoO7IKo-UkXc=.884e3dac-0dc4-43e0-a142-7613dbe6e16a@github.com>
 <82WACKaQqn2k4XPZKf50cHTTJsdwW5dqGpZhRQdYS6k=.caa9709b-5e7a-4853-833d-76f25c790c88@github.com>
Message-ID: <CxOM7AYZrHKTuCMVsRsb085k30FHABQyYkeOi9ag2XY=.68996748-8855-4665-8543-903830bb1170@github.com>

On Fri, 4 Feb 2022 13:08:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> So, do you use that also for UINTX_FORMAT?
>
> I can't recall the last time I needed to use `INTX_FORMAT` or `UINTX_FORMAT` and had kind of forgotten about them.  But yes, those seem similarly replaceable.

All right then, nevermind :)

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From shade at openjdk.java.net  Fri Feb  4 16:21:07 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Feb 2022 16:21:07 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <_02hc_OAvXGm0I9gsBw3OCHVnL9xx3B0CJyjzH5v82U=.86b2e230-1ceb-4592-86db-6786b4a35e41@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
 <MQejfQ16EQzKJp_4IiGts298qdKN4Ml2j3kaWBvG1q8=.7428c11c-5ead-4aac-b378-51f8e54b9855@github.com>
 <_02hc_OAvXGm0I9gsBw3OCHVnL9xx3B0CJyjzH5v82U=.86b2e230-1ceb-4592-86db-6786b4a35e41@github.com>
Message-ID: <Hd_LB2emf-eXFtm7JmSCA356VvH7_AT6F0r4ykAiGzk=.80f57442-3a8e-4ce3-bfd6-7058394a8463@github.com>

On Fri, 4 Feb 2022 12:31:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Intentionally didn't write it that way, because of the potential for UB pointer arithmetic overflow in `cur += page_size`.
>
> Also, that won't touch the last page when first page != last page, unless the last page is made exclusive, which calculation could also suffer from UB pointer arithmetic overflow.  Of course, the caller could suffer from that too; we can't so easily fix that.  Representing address ranges as [start, end) just generally suffers from that problem.

All right, what irked me originally is that `cur == last` break assumes both `cur` and `last` are multiples of `page_size`, otherwise this loops "indefinitely" (until successive overflows help, I guess). This is true now, but it is not even asserted. Maybe it should be `cur >= last`?

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From mbaesken at openjdk.java.net  Fri Feb  4 16:25:25 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 4 Feb 2022 16:25:25 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info
Message-ID: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>

The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.

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

Commit messages:
 - JDK-8281274

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From dcubed at openjdk.java.net  Fri Feb  4 17:25:15 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Feb 2022 17:25:15 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <wl6KF6Ij9he0EH0CjeO3vloYEeEmrI-VRI4FgC4ahpI=.6b8c955d-8f04-44e2-9bb1-436856b1cf48@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
 <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>
 <0N9FxechUMfug8q0sB98JSxgfCP_y6Amz2Y9HtaoPWw=.68c7df06-26ac-493a-84e2-4e6e65068f5f@github.com>
 <wl6KF6Ij9he0EH0CjeO3vloYEeEmrI-VRI4FgC4ahpI=.6b8c955d-8f04-44e2-9bb1-436856b1cf48@github.com>
Message-ID: <ansW-hL3thvwKdSY8nT8irBxZLm5ivH84xyil9qkfvU=.853779b5-2fd4-41ff-99fa-c157d57eb650@github.com>

On Fri, 4 Feb 2022 10:46:22 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>>> First thing to note is that `replicate` is never actually called with `count == 0`.
>> 
>> This is crucial: it means we have no UB.
>> 
>> Could I ask you to take the opportunity add a little of this commentary to the rather opaque code? Pretty please? :-)
>
>> Could I ask you to take the opportunity add a little of this commentary to the rather opaque code? Pretty please? :-)
> 
> Sure,this stuff really needs to be better documented in the code itself. I'll do that as a follow-up to this PR.

>>    First thing to note is that replicate is never actually called with count == 0.

> This is crucial: it means we have no UB.

The UB occurs when `count == 1` and `nbits == 64`.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From dcubed at openjdk.java.net  Fri Feb  4 17:25:14 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Feb 2022 17:25:14 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
Message-ID: <igddDYPW30852pPbxguxBEurDW-_PkKGssuJDn6PQrI=.3e808a75-5d2d-423a-b8ad-19202ad795bf@github.com>

On Thu, 3 Feb 2022 21:05:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
>> replicate().
>> 
>> I was not able to reproduce the reported failure using:
>> 
>>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
>> 
>> so I'm moving forward with the proposed fix from a code inspection
>> point of view.
>> 
>> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
>> no failures. Tier[3-6] are still running.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kimbarrett and adinn CR changes

@adinn or @theRealAph - I need one more reviewer to approve so I can integrate this.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From stuefe at openjdk.java.net  Fri Feb  4 17:30:11 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 17:30:11 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info
In-Reply-To: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
Message-ID: <OdMVTeHJQsPWCrVnMHOke-Q7SXxV6AshfxtiHmNmGP4=.babc9de6-9adc-4e7b-be27-fbff037c2c05@github.com>

On Fri, 4 Feb 2022 16:18:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.

Looks fine.

While looking at this I found that the default for ActiveProcessorCount is -1. The VM only reacts to this flag if it is >0. So, what is 0? The java man page is not saying. Maybe the default should just be 0 to be consistent.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7354

From adinn at openjdk.java.net  Fri Feb  4 17:31:11 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Fri, 4 Feb 2022 17:31:11 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
Message-ID: <OP8cMiTExd3X-Ero4YCSHDUN863qUOR81G0l0VRypzU=.e0ae774d-7ef4-4b51-a6bc-e3a2ac784dfa@github.com>

On Thu, 3 Feb 2022 21:05:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
>> replicate().
>> 
>> I was not able to reproduce the reported failure using:
>> 
>>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
>> 
>> so I'm moving forward with the proposed fix from a code inspection
>> point of view.
>> 
>> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
>> no failures. Tier[3-6] are still running.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kimbarrett and adinn CR changes

Marked as reviewed by adinn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From stuefe at openjdk.java.net  Fri Feb  4 17:39:12 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 17:39:12 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <WNVSezqF2f-7JUgyAm84PmtU1EVRPF0KJPALz_qNYM8=.376c4ede-9d09-4d6f-85dc-af043a4eeacf@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
 <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>
 <WNVSezqF2f-7JUgyAm84PmtU1EVRPF0KJPALz_qNYM8=.376c4ede-9d09-4d6f-85dc-af043a4eeacf@github.com>
Message-ID: <yUN7arOagrcsemLCuH90O8lGAPME9gRMlW_5huu6YhQ=.e6655e17-af6f-4ffd-9bcc-d3b46cefc661@github.com>

On Thu, 3 Feb 2022 11:22:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Looks good to me, too. I think it is ready for integration assuming all change requests were taken care of and tests have passed.
>
>> Looks good to me, too. I think it is ready for integration assuming all change requests were taken care of and tests have passed.
> 
> @TheRealMDoerr we should test the latest version of this patch in our nightlies, just in case

> > I'm a fan of more testing @tstuefe. Let me know if you discover anything interesting.
> 
> Testing is hard for us because we don't have nightly builds and tests on AIX any more. I don't know if he can afford doing much for it.

Yes, I was assuming this patch fixes JFR for all IBM platforms (also Linux PPC and s390). But this is only AIX. Maybe the issue should be renamed to reflect that. "Implement JFR on AIX". Leave that up to Martin. I think Tyler has no write access to JBS yet.



> Regarding testing: I have been regularly building and testing on my AIX 7.1 dev machine. In addition, I have run tier1 tests when the changes I'm making are complete. The only tier1 failures I observe are also failing on the master branch. I'm happy for a second tester if either of you feel it's warranted, but I don't feel it is a necessity.

I would feel better if more than tier 1 jtreg tests would be done, but I know AIX is sluggish. Maybe @egahlin can recommend what tests to run beyond tier1 to exercise JFR a bit. Are all relevant JFR tests part of tier1?

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From dcubed at openjdk.java.net  Fri Feb  4 17:40:12 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Feb 2022 17:40:12 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <OP8cMiTExd3X-Ero4YCSHDUN863qUOR81G0l0VRypzU=.e0ae774d-7ef4-4b51-a6bc-e3a2ac784dfa@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
 <OP8cMiTExd3X-Ero4YCSHDUN863qUOR81G0l0VRypzU=.e0ae774d-7ef4-4b51-a6bc-e3a2ac784dfa@github.com>
Message-ID: <467QEJGEe3fFNI0KFk_RaCn58nB-fmyiMyFernvxTmE=.8672e0f1-1cc5-423f-b1ca-066de2dd66b2@github.com>

On Fri, 4 Feb 2022 17:27:53 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kimbarrett and adinn CR changes
>
> Marked as reviewed by adinn (Reviewer).

@adinn - Thanks for the review. As you mentioned above, I'll leave it up to
you to improve the comment in a new PR.

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From dcubed at openjdk.java.net  Fri Feb  4 17:40:12 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Feb 2022 17:40:12 GMT
Subject: Integrated: 8280476: [macOS] : hotspot arm64 bug exposed by latest
 clang
In-Reply-To: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
Message-ID: <Axb8N__IT_UBJ-EH65cczsEJ_Wg7eDSaOglGHd0ETLc=.4dcd00a4-fd3d-4c6c-ac09-38a6da61e3bc@github.com>

On Fri, 28 Jan 2022 16:49:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
> replicate().
> 
> I was not able to reproduce the reported failure using:
> 
>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
> 
> so I'm moving forward with the proposed fix from a code inspection
> point of view.
> 
> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
> no failures. Tier[3-6] are still running.

This pull request has now been integrated.

Changeset: f5d6fddc
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f5d6fddc6df8c5c5456a2544b131833d5227292b
Stats:     11 lines in 1 file changed: 10 ins; 1 del; 0 mod

8280476: [macOS] : hotspot arm64 bug exposed by latest clang

Reviewed-by: kbarrett, adinn

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

PR: https://git.openjdk.java.net/jdk/pull/7270

From sgehwolf at openjdk.java.net  Fri Feb  4 17:59:10 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 4 Feb 2022 17:59:10 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info
In-Reply-To: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
Message-ID: <ZAK-HQWYumtuLxIHsfeNxjn2q_R7OLQGyToldj5yqIw=.ee58fd98-de06-4943-84d7-443610550244@github.com>

On Fri, 4 Feb 2022 16:18:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.

Marked as reviewed by sgehwolf (Reviewer).

Hmm, not sure why it recorded my comment as "approval".

src/hotspot/os/linux/os_linux.cpp line 2178:

> 2176:   if (i > 0) {
> 2177:     if (ActiveProcessorCount > 0) {
> 2178:       st->print_cr("%d, but overwritten by flag ActiveProcessorCount: %d",

This will print the same number (processor count) twice. I'd suggest to only add a blurb like `" overridden by -XX:ActiveProcessorCount"` in case the flag is set and not print the blurb otherwise.

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

PR: https://git.openjdk.java.net/jdk/pull/7354Changes requested by sgehwolf (Reviewer).

From sgehwolf at openjdk.java.net  Fri Feb  4 17:59:10 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 4 Feb 2022 17:59:10 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info
In-Reply-To: <ZAK-HQWYumtuLxIHsfeNxjn2q_R7OLQGyToldj5yqIw=.ee58fd98-de06-4943-84d7-443610550244@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <ZAK-HQWYumtuLxIHsfeNxjn2q_R7OLQGyToldj5yqIw=.ee58fd98-de06-4943-84d7-443610550244@github.com>
Message-ID: <p6rivccfCSzwcOBt9dmTIJyhAqp-ixgX-EnpGmf7fnY=.4f7d97da-5161-4ab9-8ed8-ab4b051f1e8f@github.com>

On Fri, 4 Feb 2022 17:52:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
>> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.
>
> src/hotspot/os/linux/os_linux.cpp line 2178:
> 
>> 2176:   if (i > 0) {
>> 2177:     if (ActiveProcessorCount > 0) {
>> 2178:       st->print_cr("%d, but overwritten by flag ActiveProcessorCount: %d",
> 
> This will print the same number (processor count) twice. I'd suggest to only add a blurb like `" overridden by -XX:ActiveProcessorCount"` in case the flag is set and not print the blurb otherwise.

Asserting the new output in the jtreg test would be good to have too.

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From ccheung at openjdk.java.net  Fri Feb  4 18:08:10 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 4 Feb 2022 18:08:10 GMT
Subject: RFR: 8280767: -XX:ArchiveClassesAtExit does not archive
 BoundMethodHandle$Species classes [v3]
In-Reply-To: <ac5NA3KMxRqjaToAgvBMptE-iq8leuEbpuIIO-VJi-Y=.7f654c18-6538-4cb3-9719-687ce181b728@github.com>
References: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
 <ac5NA3KMxRqjaToAgvBMptE-iq8leuEbpuIIO-VJi-Y=.7f654c18-6538-4cb3-9719-687ce181b728@github.com>
Message-ID: <pnwWAjHvwsxs5RpHCRPi1elz_KDzxko3_QPiEMMDNYk=.b9c58782-f4b6-4e4c-93a0-da8a4d40bcb8@github.com>

On Fri, 4 Feb 2022 15:44:47 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   When do dynamic dump, the call to LambdaForInvolkers::append_filtered for generating lambda holder classes will only allow the result which matches the filtering list to be added . This filters out the SPECIES method handle holder classes, and they won't be archived in dynamic shared archive. The patch is doing followings:
>>   1) Removed the call to  LambdaForInvolkers::append_filtered, instead just call LambdaForInvolkers::append so the SPECIES can be added to the regeneration list.
>>   2) Added an enum for  shared flag in Klass, _generated to indicate the class is regenerated and it should not be loaded from CDS if CFLH is enabled. If the class is a SPECIES and also loaded from base archive, skip regenerating it for dynamic archive.
>>   3) If CFLH is enabled, for regenerated classes, avoid calling CFLH.
>> 
>> Tests: tier1,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed comment

Looks good. Please add a comment in the test case.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestLambdaInvokers.java line 60:

> 58:              mainClass)
> 59:              .assertNormalExit(output -> {
> 60:                  output.shouldContain("java.lang.invoke.BoundMethodHandle$Species_JL source: shared objects file (top)");

Please add a comment indicating the "species" class is from the "CDSLambdaInvoker" test program.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7329

From jbhateja at openjdk.java.net  Fri Feb  4 18:24:12 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 4 Feb 2022 18:24:12 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
 <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
 <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>
Message-ID: <27k3oROE0euIIuvPQUavgo-xCybjqoksNx5PYyO6MJU=.b46bcf6c-c772-4284-b8b7-a9e2188e6632@github.com>

On Fri, 4 Feb 2022 15:47:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I believe it was https://bugs.openjdk.java.net/browse/JDK-8007074. Wasn't that the reason that large page memory on Linux gets committed right away when reserving?
>
> Yes, it was.

MAP_FIXED semantics are clear here, any existing reserved mapping will get overridden if a new commit happens over it, but only if new commit happens over the existing reserved address space, reservation takes a NULL address argument and returns the block of virtual memory which can be committed by binding it to large pages, since we are not bookkeeping the reserved memory space for any subsequent commit hence won't any unreserved virtual memory from a previous commit failure cause a leak in the virtual address space.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From minqi at openjdk.java.net  Fri Feb  4 18:39:48 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 4 Feb 2022 18:39:48 GMT
Subject: RFR: 8280767: -XX:ArchiveClassesAtExit does not archive
 BoundMethodHandle$Species classes [v4]
In-Reply-To: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
References: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
Message-ID: <f8UQX4wA6HMHYqJZVhhNbr40pEF0aaB70HowaAkvPCc=.19210029-4002-4530-b2a4-b2ade7cad266@github.com>

> Hi, Please review
> 
>   When do dynamic dump, the call to LambdaForInvolkers::append_filtered for generating lambda holder classes will only allow the result which matches the filtering list to be added . This filters out the SPECIES method handle holder classes, and they won't be archived in dynamic shared archive. The patch is doing followings:
>   1) Removed the call to  LambdaForInvolkers::append_filtered, instead just call LambdaForInvolkers::append so the SPECIES can be added to the regeneration list.
>   2) Added an enum for  shared flag in Klass, _generated to indicate the class is regenerated and it should not be loaded from CDS if CFLH is enabled. If the class is a SPECIES and also loaded from base archive, skip regenerating it for dynamic archive.
>   3) If CFLH is enabled, for regenerated classes, avoid calling CFLH.
> 
> Tests: tier1,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Add comment to test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7329/files
  - new: https://git.openjdk.java.net/jdk/pull/7329/files/1ef457d6..d5115e4d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7329&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7329&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/7329

From minqi at openjdk.java.net  Fri Feb  4 19:23:12 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 4 Feb 2022 19:23:12 GMT
Subject: RFR: 8280767: -XX:ArchiveClassesAtExit does not archive
 BoundMethodHandle$Species classes [v2]
In-Reply-To: <TA9n-Hf1fWF9jll3KB9-tvALC4Dtr0tGmcmlML5LVzc=.676dbea7-87da-41fb-8e26-d0e43d8fa7b2@github.com>
References: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
 <zVW-nr_7Lfr2stFYg_g1f_mqtCwBqt0EiW8nj_zYKP4=.0719db9b-6f10-4b67-9671-3389827d9861@github.com>
 <TA9n-Hf1fWF9jll3KB9-tvALC4Dtr0tGmcmlML5LVzc=.676dbea7-87da-41fb-8e26-d0e43d8fa7b2@github.com>
Message-ID: <zEOLs4EQVNTnZs-AHfboFcR39P2MGLvWOuj3yXUf6a4=.42b41b2c-03b8-406b-b495-722d8f056cda@github.com>

On Fri, 4 Feb 2022 06:53:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid call CFLH for regenerated lambda holder classes, reversed change for is_hidden_lambda_proxy
>
> LGTM. A small nit on the comments.

@iklam @calvinccheung Thanks for review

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

PR: https://git.openjdk.java.net/jdk/pull/7329

From minqi at openjdk.java.net  Fri Feb  4 19:23:14 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 4 Feb 2022 19:23:14 GMT
Subject: Integrated: 8280767: -XX:ArchiveClassesAtExit does not archive
 BoundMethodHandle$Species classes
In-Reply-To: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
References: <VK50h6i7xAGYs_R_7HHGLOv7GjgM6VaqIfxno5ciBWc=.750f8760-bf50-42be-9553-7d16c14cfaff@github.com>
Message-ID: <EC-NUElM3FwzPzgTNSkjSY5roInrnI84S6DfWXWym3o=.ed03ba60-1f36-4f8b-a3a6-be61bddd94b9@github.com>

On Wed, 2 Feb 2022 23:26:32 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
> 
>   When do dynamic dump, the call to LambdaForInvolkers::append_filtered for generating lambda holder classes will only allow the result which matches the filtering list to be added . This filters out the SPECIES method handle holder classes, and they won't be archived in dynamic shared archive. The patch is doing followings:
>   1) Removed the call to  LambdaForInvolkers::append_filtered, instead just call LambdaForInvolkers::append so the SPECIES can be added to the regeneration list.
>   2) Added an enum for  shared flag in Klass, _generated to indicate the class is regenerated and it should not be loaded from CDS if CFLH is enabled. If the class is a SPECIES and also loaded from base archive, skip regenerating it for dynamic archive.
>   3) If CFLH is enabled, for regenerated classes, avoid calling CFLH.
> 
> Tests: tier1,tier4
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: 8e4ef818
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e4ef818a90de35ae75e7f82a780653d623bb29c
Stats:     174 lines in 7 files changed: 159 ins; 7 del; 8 mod

8280767: -XX:ArchiveClassesAtExit does not archive BoundMethodHandle$Species classes

Reviewed-by: iklam, ccheung

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

PR: https://git.openjdk.java.net/jdk/pull/7329

From duke at openjdk.java.net  Fri Feb  4 19:40:23 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Feb 2022 19:40:23 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v19]
In-Reply-To: <yUN7arOagrcsemLCuH90O8lGAPME9gRMlW_5huu6YhQ=.e6655e17-af6f-4ffd-9bcc-d3b46cefc661@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <hI_-UF_us4DOCjAdk1g_cNhCsc-mPXa34OliuFG1Q4Y=.9d709089-e2ec-481c-b291-aec919483ec5@github.com>
 <2Cpm223PG1Fqsz_H-p6o7qAZbR9ojl7eSYiHYdLdJ6M=.12a6b1d1-eed3-420f-8283-490d35d37f71@github.com>
 <WNVSezqF2f-7JUgyAm84PmtU1EVRPF0KJPALz_qNYM8=.376c4ede-9d09-4d6f-85dc-af043a4eeacf@github.com>
 <yUN7arOagrcsemLCuH90O8lGAPME9gRMlW_5huu6YhQ=.e6655e17-af6f-4ffd-9bcc-d3b46cefc661@github.com>
Message-ID: <7_RBQjRF-6wQL7CDPihG0mdgqeM2nJUUxbHzjZOKodE=.0d431ab5-4b8f-4ef1-a6d9-b113720f210c@github.com>

On Fri, 4 Feb 2022 17:35:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I think Tyler has no write access to JBS yet.

This is correct.

> Are all relevant JFR tests part of tier1?

I run the tests in `test/jdk/jdk/jfr` as I develop as well, so those have been run whether or not they are part of the tier1 tests. I have also created a recording using jcmd, and analyzed it with jmc. Things are working as I expect them to :-)

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From dholmes at openjdk.java.net  Fri Feb  4 22:10:11 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 4 Feb 2022 22:10:11 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info
In-Reply-To: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
Message-ID: <6cDgc87mA5C5mDt_LYDUh4ed35aWTcRTdWf_1DF0ooI=.22a2a531-33d6-488f-a8e4-95f0a50c1c48@github.com>

On Fri, 4 Feb 2022 16:18:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.

Seems fine to me.

Does make me wonder whether other info we present can be overridden by flags.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7354

From dholmes at openjdk.java.net  Fri Feb  4 22:10:12 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 4 Feb 2022 22:10:12 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info
In-Reply-To: <p6rivccfCSzwcOBt9dmTIJyhAqp-ixgX-EnpGmf7fnY=.4f7d97da-5161-4ab9-8ed8-ab4b051f1e8f@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <ZAK-HQWYumtuLxIHsfeNxjn2q_R7OLQGyToldj5yqIw=.ee58fd98-de06-4943-84d7-443610550244@github.com>
 <p6rivccfCSzwcOBt9dmTIJyhAqp-ixgX-EnpGmf7fnY=.4f7d97da-5161-4ab9-8ed8-ab4b051f1e8f@github.com>
Message-ID: <2ZGqmniub_ncGCHTrmnNqiDxkywpNiFIvmRAA6pFkMA=.e545a043-a3da-4fe4-87a7-ca307ca34543@github.com>

On Fri, 4 Feb 2022 17:54:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 2178:
>> 
>>> 2176:   if (i > 0) {
>>> 2177:     if (ActiveProcessorCount > 0) {
>>> 2178:       st->print_cr("%d, but overwritten by flag ActiveProcessorCount: %d",
>> 
>> This will print the same number (processor count) twice. I'd suggest to only add a blurb like `" overridden by -XX:ActiveProcessorCount"` in case the flag is set and not print the blurb otherwise.
>
> Asserting the new output in the jtreg test would be good to have too.

This format is fine me with me. You want to see both the container processor count and the actual count being used.

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From kbarrett at openjdk.java.net  Sat Feb  5 08:19:18 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 5 Feb 2022 08:19:18 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch [v2]
In-Reply-To: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
Message-ID: <3wk3R9tOWF2ewKxyFaMgJ9SppsekYsIYkGediUSrKAQ=.13ac7844-0fad-4313-9ba7-57b310ab4e73@github.com>

> [Trying again, after a couple previous proposals.]
> 
> Please review this change to os::pretouch_memory to permit use of the memory
> being pretouched concurrently with the pretouch operation.  This will allow
> future changes that can make use of such overlap.
> 
> Testing:
> mach5 tier1-3 with -XX:+AlwaysPreTouch.
> 
> Verified no performance impact by comparing startup times with Epsilon GC and
> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
> 
> None of these test concurrent use; that will wait for future changes that use
> the new feature.

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

  assert range is valid

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7343/files
  - new: https://git.openjdk.java.net/jdk/pull/7343/files/7b98f359..a80ac44f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7343&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7343&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From shade at openjdk.java.net  Mon Feb  7 07:35:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Feb 2022 07:35:32 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers to "unit"
Message-ID: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>

This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".


  product_pd(intx, StackYellowPages, \
          "Number of yellow zone (recoverable overflows) pages of size " \
          "4KB. If pages are bigger yellow zone is aligned up.") \
          range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \


We can rename it for clarity.

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From mbaesken at openjdk.java.net  Mon Feb  7 08:31:36 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 7 Feb 2022 08:31:36 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v2]
In-Reply-To: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
Message-ID: <g7kPTAOk-OM4hU_KTn9wXUGIe6Ia8OjjRsUTXHB5_oM=.fe737b55-326c-4a4f-a1bc-0fb9f508e727@github.com>

> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.

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

  Adjust output

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7354/files
  - new: https://git.openjdk.java.net/jdk/pull/7354/files/2d845456..e8b8101a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7354&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7354&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From mbaesken at openjdk.java.net  Mon Feb  7 08:35:09 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 7 Feb 2022 08:35:09 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v2]
In-Reply-To: <2ZGqmniub_ncGCHTrmnNqiDxkywpNiFIvmRAA6pFkMA=.e545a043-a3da-4fe4-87a7-ca307ca34543@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <ZAK-HQWYumtuLxIHsfeNxjn2q_R7OLQGyToldj5yqIw=.ee58fd98-de06-4943-84d7-443610550244@github.com>
 <p6rivccfCSzwcOBt9dmTIJyhAqp-ixgX-EnpGmf7fnY=.4f7d97da-5161-4ab9-8ed8-ab4b051f1e8f@github.com>
 <2ZGqmniub_ncGCHTrmnNqiDxkywpNiFIvmRAA6pFkMA=.e545a043-a3da-4fe4-87a7-ca307ca34543@github.com>
Message-ID: <vzSUh2Yc1ErAKuNwb6sYJMUgyb5yC3R_nFIJSXM41nY=.20feda77-553b-4373-bd53-f4fcfcb7e2e4@github.com>

On Fri, 4 Feb 2022 22:05:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Asserting the new output in the jtreg test would be good to have too.
>
> This format is fine me with me. You want to see both the container processor count and the actual count being used.

Hi  Severin , I adjusted the output following your suggestion  (David, in case ActiveProcessorCount  is set on the command line it is printed as well , see Arguments::print_summary_on , probably that's why Severin does not want it  here.
Regarding ,  whether other info we present can be overridden by flags, I think not in the container area  (not sure about the whole hs_err output).

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From duke at openjdk.java.net  Mon Feb  7 08:36:12 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 7 Feb 2022 08:36:12 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>

On Fri, 4 Feb 2022 12:50:49 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

> Hi @swati-sha and @tstuefe,
> 
> I was thinking the same thing, that you should see this PR :)
> 
> As mentioned this was discussed a lot in the review for [JDK-8256155](https://bugs.openjdk.java.net/browse/JDK-8256155). That said, I think there is room for improvement. What we settled on back then was that if any large page size passed the sanity check we consider large pages enabled. It can then of course look strange in some cases, but often when things are not working as expected it is because of some configuration "issue".
> 
> I suspect that the problem you are running into is that the default large page size is 1G, but you only have 2M pages configured. The simple work-around for this issue would be to specify `-XX:LargePageSizeInBytes=2m` but it would of course be good if it worked out of the box.
> 
> I did play around a bit trying to solve this, but it got shelved. I did try to solve it in the `ReservedSpace` layer instead. This would satisfy Thomas comment about not relying to much on checks at startup. I did something like:
> 
> ```diff
>     diff --git a/src/hotspot/share/memory/virtualspace.cpp b/src/hotspot/share/memory/virtualspace.cpp
> index c5f682bb31f..80d0910f150 100644
> --- a/src/hotspot/share/memory/virtualspace.cpp
> +++ b/src/hotspot/share/memory/virtualspace.cpp
> @@ -235,11 +235,20 @@ void ReservedSpace::reserve(size_t size,
>      // the caller requested large pages. To satisfy this request we use
>      // explicit large pages and these have to be committed up front to ensure
>      // no reservations are lost.
> +    size_t used_page_size = page_size;
> +    char* base = NULL;
> +
> +    do {
> +      base = reserve_memory_special(requested_address, size, alignment, used_page_size, executable);
> +      if (base != NULL) {
> +        break;
> +      }
> +      used_page_size = os::page_sizes().next_smaller(used_page_size);
> +    } while (used_page_size > (size_t) os::vm_page_size());
>  
> -    char* base = reserve_memory_special(requested_address, size, alignment, page_size, executable);
>      if (base != NULL) {
>        // Successful reservation using large pages.
> -      initialize_members(base, size, alignment, page_size, true, executable);
> +      initialize_members(base, size, alignment, used_page_size, true, executable);
>        return;
>      }
>      // Failed to reserve explicit large pages, fall back to normal reservation.
> ```
> 
> This is completely untested, and there might be some other tweaks needed to make it work. What do you think about this kind of approach?

Hi @kstefanj ,

Your proposed fix is not going to fix the alignment which will be incorrect wrt. the page_size and it may result 
into internal fragmentation within virtual address space which by the way is not a constraint but is a minor functional issue.
Also we are leaving incorrect value in _large_page_size(global variable) which is being used at several places.

Seek your opinion if above issues will not impact the functionality in any manner.

Thanks and Regards, 
Swati Sharma

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From mbaesken at openjdk.java.net  Mon Feb  7 08:39:03 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 7 Feb 2022 08:39:03 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v2]
In-Reply-To: <OdMVTeHJQsPWCrVnMHOke-Q7SXxV6AshfxtiHmNmGP4=.babc9de6-9adc-4e7b-be27-fbff037c2c05@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <OdMVTeHJQsPWCrVnMHOke-Q7SXxV6AshfxtiHmNmGP4=.babc9de6-9adc-4e7b-be27-fbff037c2c05@github.com>
Message-ID: <KL2HVC5vbF1HdcrJtSE8j9iLF5vfqPaj78k5QqR68R4=.4d8ea580-83ad-445f-a896-fa3ecd102005@github.com>

On Fri, 4 Feb 2022 17:26:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Looks fine.
> 
> While looking at this I found that the default for ActiveProcessorCount is -1. The VM only reacts to this flag if it is >0. So, what is 0? The java man page is not saying. Maybe the default should just be 0 to be consistent.

Thanks for the review. Indeed only ActiveProcessorCount  > 0  results in special handling, so 0 and -1 are both leading to the same runtime behavior.

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From sjohanss at openjdk.java.net  Mon Feb  7 09:37:06 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 09:37:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
Message-ID: <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>

On Mon, 7 Feb 2022 08:32:53 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Your proposed fix is not going to fix the alignment which will be incorrect wrt. the page_size and it may result into internal fragmentation within virtual address space which by the way is not a constraint but is a minor functional issue. Also we are leaving incorrect value in _large_page_size(global variable) which is being used at several places.
> 
Correct, the alignment will be that of the initial requested/configured large page size, but any smaller large page size will still be aligned wrt to this alignment. I don't see any real problem with this. Sure we will require the reservation to be aligned to something larger that finally needed, but given that the number of such reservations won't be very many I think using this kind of fallback mechanism is ok.
 
Regarding the value left in `_large_page_size`, yes at startup this value was not usable but it is the configured value for the JVM (either by being the default for the system or by passing LargePageSizeInBytes). The discussions in the passed have lead to not changing this since that might lead to more confusing behavior. 

> Seek your opinion if above issues will not impact the functionality in any manner.

One problem, that is kind of related to this (and also was on my backlog to investigate), is that we are using `os::large_page_size()` as the alignment for the heap. This means that if you request a 128m heap with a 512m large page size the heap will be aligned up to 512m. This happens regardless if 512m pages are available or not, so it is kind of a different issue. The heap alignment should probably do something similar as other reservations and use ?os::page_size_for_region(...)?. There might also be additional things related to this, where the use of `os::large_page_size()` should be looked at because we allow multiple large page sizes to be used.

Another thing that has been discussed in the passed is how to handle the logging around this. Currently you need to enable logging with `pagesize` (`-Xlog:pagesize`) to get feedback on the configuration, it might make sense to move parts of this to a level that is always shown: 

[0.001s][info][pagesize] Using the default large page size: 512M
[0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
[0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
[0.001s][info][pagesize] Large page size (2M) passed sanity check

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From mdoerr at openjdk.java.net  Mon Feb  7 10:29:11 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 7 Feb 2022 10:29:11 GMT
Subject: RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712
 (Flight Recorder) [v20]
In-Reply-To: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
Message-ID: <hMYVGzquS5A3h3WAGPY63wSwqDRHjewl5sAiAtEK9bk=.70f129a5-cd67-4c98-918d-3c668db9aa5b@github.com>

On Fri, 4 Feb 2022 00:25:43 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

I've updated the JBS issue. Please adapt the PR title to match it: "[AIX] Check functionality of JDK-8199712 (Flight Recorder)".

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From sjohanss at openjdk.java.net  Mon Feb  7 10:30:14 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 10:30:14 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <27k3oROE0euIIuvPQUavgo-xCybjqoksNx5PYyO6MJU=.b46bcf6c-c772-4284-b8b7-a9e2188e6632@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
 <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
 <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>
 <27k3oROE0euIIuvPQUavgo-xCybjqoksNx5PYyO6MJU=.b46bcf6c-c772-4284-b8b7-a9e2188e6632@github.com>
Message-ID: <vfbTMG8rQ-LaPfQMFFg5ADGb_nlkpGelT6-Xu4HMcJw=.3d9edb45-7b9b-40b7-bea6-ce36b2e00635@github.com>

On Fri, 4 Feb 2022 18:20:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yes, it was.
>
> MAP_FIXED semantics are clear here, any existing reserved mapping will get overridden if a new commit happens over it, but only if new commit happens over the existing reserved address space, reservation takes a NULL address argument and returns the block of virtual memory which can be committed by binding it to large pages, since we are not bookkeeping the reserved memory space for any subsequent commit hence won't any unreserved virtual memory from a previous commit failure cause a leak in the virtual address space.

I'm sorry, I don't fully follow your reasoning. Are you agreeing that this is not a problem?

To re-iterate what we have seen in the past: a reservation passing a NULL argument as the requested address is mapped on an address where a failed large page commit occurred (for this to happen, the previous reservation must have been release by the failure). This has lead us to require that the complete reservation is committed up front when using large pages, because we cannot risk loosing part of a reservation later in the execution. 

You can read more about this in the bug linked by @tstuefe and I think [this comments](https://bugs.openjdk.java.net/browse/JDK-8007074?focusedCommentId=13306490&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13306490) and the ones below explain the problem very well.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From sgehwolf at openjdk.java.net  Mon Feb  7 11:01:09 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 7 Feb 2022 11:01:09 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v2]
In-Reply-To: <2ZGqmniub_ncGCHTrmnNqiDxkywpNiFIvmRAA6pFkMA=.e545a043-a3da-4fe4-87a7-ca307ca34543@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <ZAK-HQWYumtuLxIHsfeNxjn2q_R7OLQGyToldj5yqIw=.ee58fd98-de06-4943-84d7-443610550244@github.com>
 <p6rivccfCSzwcOBt9dmTIJyhAqp-ixgX-EnpGmf7fnY=.4f7d97da-5161-4ab9-8ed8-ab4b051f1e8f@github.com>
 <2ZGqmniub_ncGCHTrmnNqiDxkywpNiFIvmRAA6pFkMA=.e545a043-a3da-4fe4-87a7-ca307ca34543@github.com>
Message-ID: <QsoaCXDT-7ttdE_yPmAc6ukixaooqLLnA-9k9-m7wnk=.d6a062e2-3994-406a-bf34-0e240b11f674@github.com>

On Fri, 4 Feb 2022 22:05:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Asserting the new output in the jtreg test would be good to have too.
>
> This format is fine me with me. You want to see both the container processor count and the actual count being used.

Sorry, I was wrong. I misread `int i = OSContainer::active_processor_count();` for `int i = os::active_processor_count();` which would then return the same value. As @dholmes-ora said, the original format was fine. Please add this in the test, though. Could be akin to `test/hotspot/jtreg/containers/docker/TestMisc.testPrintContainerInfo()`. I.e. set some CPU quota and also ActiveProcessorCount and assert the message in log output.

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From jbhateja at openjdk.java.net  Mon Feb  7 11:51:09 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 7 Feb 2022 11:51:09 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <vfbTMG8rQ-LaPfQMFFg5ADGb_nlkpGelT6-Xu4HMcJw=.3d9edb45-7b9b-40b7-bea6-ce36b2e00635@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
 <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
 <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>
 <27k3oROE0euIIuvPQUavgo-xCybjqoksNx5PYyO6MJU=.b46bcf6c-c772-4284-b8b7-a9e2188e6632@github.com>
 <vfbTMG8rQ-LaPfQMFFg5ADGb_nlkpGelT6-
 Xu4HMcJw=.3d9edb45-7b9b-40b7-bea6-ce36b2e00635@github.com>
Message-ID: <NXkBm0IcuOoTkswSGiHrGZgn_vak2T3lraSK3XNKEPs=.c9b4329f-4a48-4d14-9d3b-f14f5bc89201@github.com>

On Mon, 7 Feb 2022 10:27:00 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> MAP_FIXED semantics are clear here, any existing reserved mapping will get overridden if a new commit happens over it, but only if new commit happens over the existing reserved address space, reservation takes a NULL address argument and returns the block of virtual memory which can be committed by binding it to large pages, since we are not bookkeeping the reserved memory space for any subsequent commit hence won't any unreserved virtual memory from a previous commit failure cause a leak in the virtual address space.
>
> I'm sorry, I don't fully follow your reasoning. Are you agreeing that this is not a problem?
> 
> To re-iterate what we have seen in the past: a reservation passing a NULL argument as the requested address is mapped on an address where a failed large page commit occurred (for this to happen, the previous reservation must have been release by the failure). This has lead us to require that the complete reservation is committed up front when using large pages, because we cannot risk loosing part of a reservation later in the execution. 
> 
> You can read more about this in the bug linked by @tstuefe and I think [this comments](https://bugs.openjdk.java.net/browse/JDK-8007074?focusedCommentId=13306490&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13306490) and the ones below explain the problem very well.

Yes, it seem this may turn to be not-a-bug.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Mon Feb  7 12:18:08 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 7 Feb 2022 12:18:08 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
Message-ID: <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>

On Mon, 7 Feb 2022 09:33:34 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > Your proposed fix is not going to fix the alignment which will be incorrect wrt. the page_size and it may result into internal fragmentation within virtual address space which by the way is not a constraint but is a minor functional issue. Also we are leaving incorrect value in _large_page_size(global variable) which is being used at several places.
> 
> Correct, the alignment will be that of the initial requested/configured large page size, but any smaller large page size will still be aligned wrt to this alignment. I don't see any real problem with this. Sure we will require the reservation to be aligned to something larger that finally needed, but given that the number of such reservations won't be very many I think using this kind of fallback mechanism is ok.
> 
> Regarding the value left in `_large_page_size`, yes at startup this value was not usable but it is the configured value for the JVM (either by being the default for the system or by passing LargePageSizeInBytes). The discussions in the passed have lead to not changing this since that might lead to more confusing behavior.
> 
> > Seek your opinion if above issues will not impact the functionality in any manner.
> 
> One problem, that is kind of related to this (and also was on my backlog to investigate), is that we are using `os::large_page_size()` as the alignment for the heap. This means that if you request a 128m heap with a 512m large page size the heap will be aligned up to 512m. This happens regardless if 512m pages are available or not, so it is kind of a different issue. The heap alignment should probably do something similar as other reservations and use ?os::page_size_for_region(...)?. There might also be additional things related to this, where the use of `os::large_page_size()` should be looked at because we allow multiple large page sizes to be used.
> 
> Another thing that has been discussed in the passed is how to handle the logging around this. Currently you need to enable logging with `pagesize` (`-Xlog:pagesize`) to get feedback on the configuration, it might make sense to move parts of this to a level that is always shown:
> 
> ```
> [0.001s][info][pagesize] Using the default large page size: 512M
> [0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
> [0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
> [0.001s][info][pagesize] Large page size (2M) passed sanity check
> ```

Hi @kstefanj ,

Are you suggesting that its ok not to honor the alignment which is based on the original large page size?

Thanks and Regards,
Swati Sharma

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From jbhateja at openjdk.java.net  Mon Feb  7 12:57:08 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 7 Feb 2022 12:57:08 GMT
Subject: RFR: 8281263: virtual space leakage if large page commit fails.
In-Reply-To: <GB2yuKxKcQHngEo432Y-6ETH6bfaSAV_2sONpdgiaPY=.f4ec78a2-47cb-4503-9ef2-b9311890a145@github.com>
References: <GB2yuKxKcQHngEo432Y-6ETH6bfaSAV_2sONpdgiaPY=.f4ec78a2-47cb-4503-9ef2-b9311890a145@github.com>
Message-ID: <mcaOm8JQEv-eC69F0wOR7IVg5CFaTJPT3odOsRw06Ds=.3b7ba51b-5bf7-469b-8e21-613d78a8aba2@github.com>

On Fri, 4 Feb 2022 13:27:58 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Hi Team,
> 
> In this patch I have fixed the virtual space leakage issue. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> Please review and provide your valuable comments.
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

MAP_FIXED flag is clear on the semantics here, it will override the earlier mapping and which will unreserve the memory in case of commit failure.

Closing this PR which was spun out of discussion on [PR 7326](https://github.com/openjdk/jdk/pull/7326)

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

PR: https://git.openjdk.java.net/jdk/pull/7350

From duke at openjdk.java.net  Mon Feb  7 12:57:08 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 7 Feb 2022 12:57:08 GMT
Subject: Withdrawn: 8281263: virtual space leakage if large page commit fails.
In-Reply-To: <GB2yuKxKcQHngEo432Y-6ETH6bfaSAV_2sONpdgiaPY=.f4ec78a2-47cb-4503-9ef2-b9311890a145@github.com>
References: <GB2yuKxKcQHngEo432Y-6ETH6bfaSAV_2sONpdgiaPY=.f4ec78a2-47cb-4503-9ef2-b9311890a145@github.com>
Message-ID: <toUmd_88rDQpeD_Ah5nVEPBrJ2hDr77SoHWkV-VHLLM=.d00ff577-0b7b-43b2-984a-cdf99cec9052@github.com>

On Fri, 4 Feb 2022 13:27:58 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Hi Team,
> 
> In this patch I have fixed the virtual space leakage issue. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> Please review and provide your valuable comments.
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/7350

From sjohanss at openjdk.java.net  Mon Feb  7 13:26:05 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 13:26:05 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
 <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
Message-ID: <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>

On Mon, 7 Feb 2022 12:15:03 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Are you suggesting that its ok not to honor the alignment which is based on the original large page size?

Hi @swati-sha, 

Not really, we need to make sure the alignment is honored wrt the large page size used (using a larger alignment is still fine though). But I think it would be good to investigate if we could do better during startup if multiple large page sizes are available. I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m. Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Mon Feb  7 13:45:33 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Mon, 7 Feb 2022 13:45:33 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead in
 interpreter
Message-ID: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>

Fixes

`bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`

eliminating frequent generation of log messages irrespectively of logging configuration

Verification: N/A (the issue does not have an observable effect)

Regression: hotspot_compiler (20.04 on amd86 )

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

Commit messages:
 - JDK-8281195

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From stuefe at openjdk.java.net  Mon Feb  7 14:34:03 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 7 Feb 2022 14:34:03 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
 <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
 <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>
Message-ID: <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>

On Mon, 7 Feb 2022 13:23:20 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m. 

I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475

> Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.

I would actually like the following behavior:
- LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
- when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).

I think this is close to what we do now.

So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
- a single 1G page and 256 2m pages for the heap
- 128 2m pages for the code cache
... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.

Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From mbaesken at openjdk.java.net  Mon Feb  7 14:34:34 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 7 Feb 2022 14:34:34 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v3]
In-Reply-To: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
Message-ID: <vJGBkB9hZoArr_NJqj3x2kp03C6zgxT5iIuC3j01wx0=.fe6ddf04-c749-4154-b150-24241cacd4ac@github.com>

> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.

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

  Adjust output again, adjust test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7354/files
  - new: https://git.openjdk.java.net/jdk/pull/7354/files/e8b8101a..52fee02c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7354&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7354&range=01-02

  Stats: 13 lines in 3 files changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7354/head:pull/7354

PR: https://git.openjdk.java.net/jdk/pull/7354

From mbaesken at openjdk.java.net  Mon Feb  7 14:34:36 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 7 Feb 2022 14:34:36 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v3]
In-Reply-To: <2ZGqmniub_ncGCHTrmnNqiDxkywpNiFIvmRAA6pFkMA=.e545a043-a3da-4fe4-87a7-ca307ca34543@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <ZAK-HQWYumtuLxIHsfeNxjn2q_R7OLQGyToldj5yqIw=.ee58fd98-de06-4943-84d7-443610550244@github.com>
 <p6rivccfCSzwcOBt9dmTIJyhAqp-ixgX-EnpGmf7fnY=.4f7d97da-5161-4ab9-8ed8-ab4b051f1e8f@github.com>
 <2ZGqmniub_ncGCHTrmnNqiDxkywpNiFIvmRAA6pFkMA=.e545a043-a3da-4fe4-87a7-ca307ca34543@github.com>
Message-ID: <4XI1ITVOcNycc-02fUFHN9NSF6PSq2PfchtCmoPyVeo=.c795f519-eb3c-44bf-aadc-4d85b78b9923@github.com>

On Fri, 4 Feb 2022 22:05:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Asserting the new output in the jtreg test would be good to have too.
>
> This format is fine me with me. You want to see both the container processor count and the actual count being used.

> Sorry, I was wrong. I misread `int i = OSContainer::active_processor_count();` for `int i = os::active_processor_count();` which would then return the same value. As @dholmes-ora said, the original format was fine. Please add this in the test, though. Could be akin to `test/hotspot/jtreg/containers/docker/TestMisc.testPrintContainerInfo()`. I.e. set some CPU quota and also ActiveProcessorCount and assert the message in log output.

Hi Severin, I adjusted the output again; also adjusted the jtreg test containers/docker/TestMisc .

Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From coleenp at openjdk.java.net  Mon Feb  7 15:10:09 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 7 Feb 2022 15:10:09 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers to "unit"
In-Reply-To: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
Message-ID: <7SUy3S7sOp66rx6q2WpnivRBf-QIr1fVDG9xkZbGyL8=.3337123b-68fa-4b52-8b1e-5615e0a6dd0e@github.com>

On Mon, 7 Feb 2022 07:27:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".
> 
> 
>   product_pd(intx, StackYellowPages, \
>           "Number of yellow zone (recoverable overflows) pages of size " \
>           "4KB. If pages are bigger yellow zone is aligned up.") \
>           range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
> 
> 
> We can rename it for clarity.

src/hotspot/share/runtime/stackOverflow.cpp line 45:

> 43:   // in 4K pages to the actual os page size. We must do this before setting
> 44:   // up minimal stack sizes etc. in os::init_2().
> 45:   size_t unit = 4*K;

I think we picked 4*k because it was the smallest page size in the platforms that we supported. I might be wrong about that but the name 'unit' should be something else indicative of why it's 4k.

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From sjohanss at openjdk.java.net  Mon Feb  7 15:13:11 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 15:13:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
 <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
 <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>
 <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>
Message-ID: <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@github.com>

On Mon, 7 Feb 2022 14:31:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
> 
> I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
> 
Thanks for digging out the JBS issue for this.

> > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
> 
> I would actually like the following behavior:
> 
>     * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
> 
>     * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
> 
> 
> I think this is close to what we do now.
> 
> So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
> 
>     * a single 1G page and 256 2m pages for the heap
> 

Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated. 

>     * 128 2m pages for the code cache
>       ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
> 
> 
> Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?

This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.

If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes). 

Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From shade at openjdk.java.net  Mon Feb  7 15:48:17 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Feb 2022 15:48:17 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers
In-Reply-To: <7SUy3S7sOp66rx6q2WpnivRBf-QIr1fVDG9xkZbGyL8=.3337123b-68fa-4b52-8b1e-5615e0a6dd0e@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
 <7SUy3S7sOp66rx6q2WpnivRBf-QIr1fVDG9xkZbGyL8=.3337123b-68fa-4b52-8b1e-5615e0a6dd0e@github.com>
Message-ID: <OTVUQAap9TXCOv-344NEorBFKij09fd4NKagQG6-UWU=.a2c09134-2267-4fcb-8bde-ce1a39379931@github.com>

On Mon, 7 Feb 2022 15:06:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".
>> 
>> 
>>   product_pd(intx, StackYellowPages, \
>>           "Number of yellow zone (recoverable overflows) pages of size " \
>>           "4KB. If pages are bigger yellow zone is aligned up.") \
>>           range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
>> 
>> 
>> We can rename it for clarity.
>
> src/hotspot/share/runtime/stackOverflow.cpp line 45:
> 
>> 43:   // in 4K pages to the actual os page size. We must do this before setting
>> 44:   // up minimal stack sizes etc. in os::init_2().
>> 45:   size_t unit = 4*K;
> 
> I think we picked 4*k because it was the smallest page size in the platforms that we supported. I might be wrong about that but the name 'unit' should be something else indicative of why it's 4k.

I was thinking that the `globals.hpp` use it in a unit-like fashion: "Number of yellow zone (recoverable overflows) pages of size 4KB". In other words, that 4K is forced by option definition. I could add a blurb to the comment itself, about the motivation for this oddity.

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From shade at openjdk.java.net  Mon Feb  7 15:55:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Feb 2022 15:55:47 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v2]
In-Reply-To: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
Message-ID: <f7s7NPfwVdQyV8Ob_FRoVz7GILkShVDHi9EzZMrIN1E=.bf6452eb-90a3-404b-8b65-64429afdadb2@github.com>

> This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".
> 
> 
>   product_pd(intx, StackYellowPages, \
>           "Number of yellow zone (recoverable overflows) pages of size " \
>           "4KB. If pages are bigger yellow zone is aligned up.") \
>           range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
> 
> 
> We can rename it for clarity.

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

  Add comment blurb

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7362/files
  - new: https://git.openjdk.java.net/jdk/pull/7362/files/6e770ab2..608ca21a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7362&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7362&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From shade at openjdk.java.net  Mon Feb  7 15:55:48 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Feb 2022 15:55:48 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v2]
In-Reply-To: <OTVUQAap9TXCOv-344NEorBFKij09fd4NKagQG6-UWU=.a2c09134-2267-4fcb-8bde-ce1a39379931@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
 <7SUy3S7sOp66rx6q2WpnivRBf-QIr1fVDG9xkZbGyL8=.3337123b-68fa-4b52-8b1e-5615e0a6dd0e@github.com>
 <OTVUQAap9TXCOv-344NEorBFKij09fd4NKagQG6-UWU=.a2c09134-2267-4fcb-8bde-ce1a39379931@github.com>
Message-ID: <pkKEYdsL-qfxm1brtOqFrsEdDIQReudQ8nFSLpF5xJI=.18f92aaf-b8ed-4505-b397-7f6c7dac59f1@github.com>

On Mon, 7 Feb 2022 15:44:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/stackOverflow.cpp line 45:
>> 
>>> 43:   // in 4K pages to the actual os page size. We must do this before setting
>>> 44:   // up minimal stack sizes etc. in os::init_2().
>>> 45:   size_t unit = 4*K;
>> 
>> I think we picked 4*k because it was the smallest page size in the platforms that we supported. I might be wrong about that but the name 'unit' should be something else indicative of why it's 4k.
>
> I was thinking that the `globals.hpp` use it in a unit-like fashion: "Number of yellow zone (recoverable overflows) pages of size 4KB". In other words, that 4K is forced by option definition. I could add a blurb to the comment itself, about the motivation for this oddity.

...like in the new commit.

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From stuefe at openjdk.java.net  Mon Feb  7 16:05:14 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 7 Feb 2022 16:05:14 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v2]
In-Reply-To: <f7s7NPfwVdQyV8Ob_FRoVz7GILkShVDHi9EzZMrIN1E=.bf6452eb-90a3-404b-8b65-64429afdadb2@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
 <f7s7NPfwVdQyV8Ob_FRoVz7GILkShVDHi9EzZMrIN1E=.bf6452eb-90a3-404b-8b65-64429afdadb2@github.com>
Message-ID: <yGuiZuljV5CtQ_o3fDKdxPQnIScCF0LGy6eeE_b7eDM=.107c6fe3-8980-48c3-abb1-85a5bc7bd336@github.com>

On Mon, 7 Feb 2022 15:55:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".
>> 
>> 
>>   product_pd(intx, StackYellowPages, \
>>           "Number of yellow zone (recoverable overflows) pages of size " \
>>           "4KB. If pages are bigger yellow zone is aligned up.") \
>>           range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
>> 
>> 
>> We can rename it for clarity.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment blurb

LGTM

src/hotspot/share/runtime/stackOverflow.cpp line 44:

> 42:   // We need to adapt the configured number of stack protection pages to the
> 43:   // actual OS page size. We must do this before setting up minimal stack
> 44:   // sizes etc. in os::init_2(). The option values are given in the 4K units,

s/in the 4K units/in 4K units

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7362

From shade at openjdk.java.net  Mon Feb  7 16:09:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Feb 2022 16:09:38 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v3]
In-Reply-To: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
Message-ID: <gek8UGdo1ECF2IzV9GdtDtcq4POCQycjup7B1UXPjBg=.97aa2aa9-3b06-4daf-b320-1ba9a39d5153@github.com>

> This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".
> 
> 
>   product_pd(intx, StackYellowPages, \
>           "Number of yellow zone (recoverable overflows) pages of size " \
>           "4KB. If pages are bigger yellow zone is aligned up.") \
>           range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
> 
> 
> We can rename it for clarity.

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

  Typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7362/files
  - new: https://git.openjdk.java.net/jdk/pull/7362/files/608ca21a..2a1db06c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7362&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7362&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From shade at openjdk.java.net  Mon Feb  7 16:09:41 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Feb 2022 16:09:41 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v2]
In-Reply-To: <yGuiZuljV5CtQ_o3fDKdxPQnIScCF0LGy6eeE_b7eDM=.107c6fe3-8980-48c3-abb1-85a5bc7bd336@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
 <f7s7NPfwVdQyV8Ob_FRoVz7GILkShVDHi9EzZMrIN1E=.bf6452eb-90a3-404b-8b65-64429afdadb2@github.com>
 <yGuiZuljV5CtQ_o3fDKdxPQnIScCF0LGy6eeE_b7eDM=.107c6fe3-8980-48c3-abb1-85a5bc7bd336@github.com>
Message-ID: <nDq66vpBkBI4kXQprj6pR_obWdMAdZeBn-5Kxo8oI7E=.9dc75895-3c12-487e-af95-6ba36be92253@github.com>

On Mon, 7 Feb 2022 16:02:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment blurb
>
> src/hotspot/share/runtime/stackOverflow.cpp line 44:
> 
>> 42:   // We need to adapt the configured number of stack protection pages to the
>> 43:   // actual OS page size. We must do this before setting up minimal stack
>> 44:   // sizes etc. in os::init_2(). The option values are given in the 4K units,
> 
> s/in the 4K units/in 4K units

Fixed!

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From shade at openjdk.java.net  Mon Feb  7 16:15:09 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Feb 2022 16:15:09 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter
In-Reply-To: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
Message-ID: <_ni6Ku-qInkRELL7xbU8dyFYfsWiiTeA4M7NX6cdGgE=.cb1f479e-76da-4225-ae94-c515c2248b04@github.com>

On Mon, 7 Feb 2022 13:32:13 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Fixes
> 
> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
> 
> eliminating frequent generation of log messages with no respect of logging configuration
> 
> Verification: N/A (the issue does not have an observable effect)
> 
> Regression: hotspot_compiler (20.04 on amd64 )

Looks interesting. Does this only affect debug builds? I see the only call to `verify_mask` is from `OopMapCacheEntry::set_mask`, and it is under `assert`.

src/hotspot/share/interpreter/oopMapCache.cpp line 282:

> 280:   bool const is_log_enabled = log_type::is_enabled();
> 281:   static const log_type log;
> 282:   LogStream st(log);

Isn't this just:


  const bool log = log_is_enabled(Trace, interpreter, oopmap);
  LogStream st(Log(interpreter, oopmap)::trace());

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

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7367

From sgehwolf at openjdk.java.net  Mon Feb  7 16:19:10 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 7 Feb 2022 16:19:10 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v3]
In-Reply-To: <vJGBkB9hZoArr_NJqj3x2kp03C6zgxT5iIuC3j01wx0=.fe6ddf04-c749-4154-b150-24241cacd4ac@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <vJGBkB9hZoArr_NJqj3x2kp03C6zgxT5iIuC3j01wx0=.fe6ddf04-c749-4154-b150-24241cacd4ac@github.com>
Message-ID: <chd2Kv8UoKu1Z_e8Jgfn7_ceKXbas5I5lj2hJfHlQRk=.7f6f4b4a-f7aa-4adb-83e9-65e6dea26306@github.com>

On Mon, 7 Feb 2022 14:34:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
>> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust output again, adjust test

Changes requested by sgehwolf (Reviewer).

test/hotspot/jtreg/containers/docker/TestMisc.java line 89:

> 87:         Common.logNewTestCase("Test print_container_info()");
> 88: 
> 89:         DockerRunOptions opts = Common.newOpts(imageName, "PrintContainerInfo", "-XX:ActiveProcessorCount=2");

It would be better to separate this specific test. More like this:
https://github.com/jerboaa/jdk/commit/3911ef81c8f280a2c0da259211b91f4c3e8c3994

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From goetz at openjdk.java.net  Mon Feb  7 16:25:05 2022
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Mon, 7 Feb 2022 16:25:05 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v3]
In-Reply-To: <pkKEYdsL-qfxm1brtOqFrsEdDIQReudQ8nFSLpF5xJI=.18f92aaf-b8ed-4505-b397-7f6c7dac59f1@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
 <7SUy3S7sOp66rx6q2WpnivRBf-QIr1fVDG9xkZbGyL8=.3337123b-68fa-4b52-8b1e-5615e0a6dd0e@github.com>
 <OTVUQAap9TXCOv-344NEorBFKij09fd4NKagQG6-UWU=.a2c09134-2267-4fcb-8bde-ce1a39379931@github.com>
 <pkKEYdsL-qfxm1brtOqFrsEdDIQReudQ8nFSLpF5xJI=.18f92aaf-b8ed-4505-b397-7f6c7dac59f1@github.com>
Message-ID: <WjdVs3gYpovPUhmIYyNFMCsS-kreIxJp4plUZRyVZUo=.50db69a6-e005-461e-8be4-717e011ccee5@github.com>

On Mon, 7 Feb 2022 15:52:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I was thinking that the `globals.hpp` use it in a unit-like fashion: "Number of yellow zone (recoverable overflows) pages of size 4KB". In other words, that 4K is forced by option definition. I could add a blurb to the comment itself, about the motivation for this oddity.
>
> ...like in the new commit.

Good point to rename this!

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From duke at openjdk.java.net  Mon Feb  7 17:21:08 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Mon, 7 Feb 2022 17:21:08 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter
In-Reply-To: <_ni6Ku-qInkRELL7xbU8dyFYfsWiiTeA4M7NX6cdGgE=.cb1f479e-76da-4225-ae94-c515c2248b04@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <_ni6Ku-qInkRELL7xbU8dyFYfsWiiTeA4M7NX6cdGgE=.cb1f479e-76da-4225-ae94-c515c2248b04@github.com>
Message-ID: <vkBmcim_HOALN5CO6clxwPA4vV6fynD8-LQIPVbSsp4=.23e4cd26-8401-4680-a4a8-b3e263ed2038@github.com>

On Mon, 7 Feb 2022 16:10:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> src/hotspot/share/interpreter/oopMapCache.cpp line 282:
> 
>> 280:   bool const is_log_enabled = log_type::is_enabled();
>> 281:   static const log_type log;
>> 282:   LogStream st(log);
> 
> Isn't this just:
> 
> 
>   const bool log = log_is_enabled(Trace, interpreter, oopmap);
>   LogStream st(Log(interpreter, oopmap)::trace());

Yes, you're right, there are many ways to say the same. Log(...)::trace() returns exactly the object represented by `log` variable. It also may be


const bool log = log_is_enabled(LogLevel::Trace, interpreter, oopmap);
LogStream st(LogTarget(LogLevel::Trace, interpreter, oopmap));

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From shade at openjdk.java.net  Mon Feb  7 17:24:08 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Feb 2022 17:24:08 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter
In-Reply-To: <vkBmcim_HOALN5CO6clxwPA4vV6fynD8-LQIPVbSsp4=.23e4cd26-8401-4680-a4a8-b3e263ed2038@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <_ni6Ku-qInkRELL7xbU8dyFYfsWiiTeA4M7NX6cdGgE=.cb1f479e-76da-4225-ae94-c515c2248b04@github.com>
 <vkBmcim_HOALN5CO6clxwPA4vV6fynD8-LQIPVbSsp4=.23e4cd26-8401-4680-a4a8-b3e263ed2038@github.com>
Message-ID: <Tl2z1HmCjV1y1PlQdiGs0E7e9dlqso1I0C69p-HkzEI=.5c7b33d4-6799-47b5-b3ec-3c4a1ae624e3@github.com>

On Mon, 7 Feb 2022 17:14:29 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> src/hotspot/share/interpreter/oopMapCache.cpp line 282:
>> 
>>> 280:   bool const is_log_enabled = log_type::is_enabled();
>>> 281:   static const log_type log;
>>> 282:   LogStream st(log);
>> 
>> Isn't this just:
>> 
>> 
>>   const bool log = log_is_enabled(Trace, interpreter, oopmap);
>>   LogStream st(Log(interpreter, oopmap)::trace());
>
> Yes, you're right, there are many ways to say the same. Log(...)::trace() returns exactly the object represented by `log` variable. It also may be
> 
> 
> const bool log = log_is_enabled(LogLevel::Trace, interpreter, oopmap);
> LogStream st(LogTarget(LogLevel::Trace, interpreter, oopmap));

Or even:


LogStreamHandle(Trace, interpreter, oopmap) st;

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Mon Feb  7 17:43:51 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Mon, 7 Feb 2022 17:43:51 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v2]
In-Reply-To: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
Message-ID: <8QkcpGFEBANDKh9Tltd8svAJxLbApldFhwXLwvTeFDg=.70a2aca7-2afe-4a9e-b371-b27a52610a14@github.com>

> Fixes
> 
> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
> 
> eliminating frequent generation of log messages with no respect of logging configuration
> 
> Verification: N/A (the issue does not have an observable effect)
> 
> Regression: hotspot_compiler (20.04 on amd64 )

Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:

  Fixing per review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7367/files
  - new: https://git.openjdk.java.net/jdk/pull/7367/files/efa8b6a4..96b73adf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7367.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7367/head:pull/7367

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Mon Feb  7 17:46:05 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Mon, 7 Feb 2022 17:46:05 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter
In-Reply-To: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
Message-ID: <DPfc_JospdXjLpwFdEjvVix18GwSiLzM1D9KGCV7daM=.a6265fae-8d4c-4908-9d34-43dd8e71a7e0@github.com>

On Mon, 7 Feb 2022 13:32:13 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Fixes
> 
> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
> 
> eliminating frequent generation of log messages with no respect of logging configuration
> 
> Verification: N/A (the issue does not have an observable effect)
> 
> Regression: hotspot_compiler (20.04 on amd64 )

That's true, seems like the problem takes place only for debug builds

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Mon Feb  7 17:54:06 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Mon, 7 Feb 2022 17:54:06 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v2]
In-Reply-To: <Tl2z1HmCjV1y1PlQdiGs0E7e9dlqso1I0C69p-HkzEI=.5c7b33d4-6799-47b5-b3ec-3c4a1ae624e3@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <_ni6Ku-qInkRELL7xbU8dyFYfsWiiTeA4M7NX6cdGgE=.cb1f479e-76da-4225-ae94-c515c2248b04@github.com>
 <vkBmcim_HOALN5CO6clxwPA4vV6fynD8-LQIPVbSsp4=.23e4cd26-8401-4680-a4a8-b3e263ed2038@github.com>
 <Tl2z1HmCjV1y1PlQdiGs0E7e9dlqso1I0C69p-HkzEI=.5c7b33d4-6799-47b5-b3ec-3c4a1ae624e3@github.com>
Message-ID: <u23uPAIOJQ9p0JNz_PntsDqi_F5jK6UbSsyAsNS7woM=.bfaaadfa-093a-4b38-a3f5-dffcfdbfd0aa@github.com>

On Mon, 7 Feb 2022 17:21:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yes, you're right, there are many ways to say the same. Log(...)::trace() returns exactly the object represented by `log` variable.
>
> Or even:
> 
> 
> LogStreamHandle(Trace, interpreter, oopmap) st;

`LogStream(Log(Trace, interpreter, oopmap)::trace)` looks as the best alternative cuz it does not use confusing "implementation" or "handle" but only public "interfaces"

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From coleenp at openjdk.java.net  Mon Feb  7 19:03:11 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 7 Feb 2022 19:03:11 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v3]
In-Reply-To: <gek8UGdo1ECF2IzV9GdtDtcq4POCQycjup7B1UXPjBg=.97aa2aa9-3b06-4daf-b320-1ba9a39d5153@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
 <gek8UGdo1ECF2IzV9GdtDtcq4POCQycjup7B1UXPjBg=.97aa2aa9-3b06-4daf-b320-1ba9a39d5153@github.com>
Message-ID: <VW4Tofmhfkk4C8ETw7BKo5z5GJCU3YLQn5nTW57J4h4=.bbd2d676-7c24-4b6c-b18b-96c7d0e60c52@github.com>

On Mon, 7 Feb 2022 16:09:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".
>> 
>> 
>>   product_pd(intx, StackYellowPages, \
>>           "Number of yellow zone (recoverable overflows) pages of size " \
>>           "4KB. If pages are bigger yellow zone is aligned up.") \
>>           range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
>> 
>> 
>> We can rename it for clarity.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

Approved and this is trivial.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7362

From xliu at openjdk.java.net  Mon Feb  7 19:03:11 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 7 Feb 2022 19:03:11 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v3]
In-Reply-To: <gek8UGdo1ECF2IzV9GdtDtcq4POCQycjup7B1UXPjBg=.97aa2aa9-3b06-4daf-b320-1ba9a39d5153@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
 <gek8UGdo1ECF2IzV9GdtDtcq4POCQycjup7B1UXPjBg=.97aa2aa9-3b06-4daf-b320-1ba9a39d5153@github.com>
Message-ID: <lYhzSpQ6g9q0ldPdjyTwjQzVQ-ruT3mheZUl8KIr71Q=.02702605-f5aa-4efd-9417-cff937f423fa@github.com>

On Mon, 7 Feb 2022 16:09:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".
>> 
>> 
>>   product_pd(intx, StackYellowPages, \
>>           "Number of yellow zone (recoverable overflows) pages of size " \
>>           "4KB. If pages are bigger yellow zone is aligned up.") \
>>           range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
>> 
>> 
>> We can rename it for clarity.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

LGTM. I am not a reviewer, we need other reviewers to approve it. 

now I see. the number 4k is deliberately chosen as 'unit', not page size. The original code was correct, but it's better to understand now.

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

Marked as reviewed by xliu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7362

From coleenp at openjdk.java.net  Mon Feb  7 19:03:11 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 7 Feb 2022 19:03:11 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v3]
In-Reply-To: <WjdVs3gYpovPUhmIYyNFMCsS-kreIxJp4plUZRyVZUo=.50db69a6-e005-461e-8be4-717e011ccee5@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
 <7SUy3S7sOp66rx6q2WpnivRBf-QIr1fVDG9xkZbGyL8=.3337123b-68fa-4b52-8b1e-5615e0a6dd0e@github.com>
 <OTVUQAap9TXCOv-344NEorBFKij09fd4NKagQG6-UWU=.a2c09134-2267-4fcb-8bde-ce1a39379931@github.com>
 <pkKEYdsL-qfxm1brtOqFrsEdDIQReudQ8nFSLpF5xJI=.18f92aaf-b8ed-4505-b397-7f6c7dac59f1@github.com>
 <WjdVs3gYpovPUhmIYyNFMCsS-kreIxJp4plUZRyVZUo=.50db69a6-e005-461e-8be4-717e011ccee5@github.com>
Message-ID: <8EDbnJXDJoJRIZrnfbQwMfbhbt9OPue3vAGxqqK8gxQ=.54a2896b-2950-4646-bcc7-457c9c44f7b6@github.com>

On Mon, 7 Feb 2022 16:22:25 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> ...like in the new commit.
>
> Good point to rename this!

Oh, ok, reading the option description helps.

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From coleenp at openjdk.java.net  Mon Feb  7 19:05:11 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 7 Feb 2022 19:05:11 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v2]
In-Reply-To: <8QkcpGFEBANDKh9Tltd8svAJxLbApldFhwXLwvTeFDg=.70a2aca7-2afe-4a9e-b371-b27a52610a14@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <8QkcpGFEBANDKh9Tltd8svAJxLbApldFhwXLwvTeFDg=.70a2aca7-2afe-4a9e-b371-b27a52610a14@github.com>
Message-ID: <eD4MrEM5W9DFhjP6TBBcsATS4FaupUQH1TxUqadE8Dc=.40311ad5-ff24-46ab-ae2c-07b9d51fa8cc@github.com>

On Mon, 7 Feb 2022 17:43:51 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing per review

src/hotspot/share/interpreter/oopMapCache.cpp line 282:

> 280:   LogStream st(Log(interpreter, oopmap)::trace());
> 281: 
> 282:   if (log) st.print("Locals (%d): ", max_locals);

This seems unfortunate to have these if statements, and a counter goal of the logging framework.  Is there another way to do this without the if statements?

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Mon Feb  7 19:38:10 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Mon, 7 Feb 2022 19:38:10 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v2]
In-Reply-To: <eD4MrEM5W9DFhjP6TBBcsATS4FaupUQH1TxUqadE8Dc=.40311ad5-ff24-46ab-ae2c-07b9d51fa8cc@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <8QkcpGFEBANDKh9Tltd8svAJxLbApldFhwXLwvTeFDg=.70a2aca7-2afe-4a9e-b371-b27a52610a14@github.com>
 <eD4MrEM5W9DFhjP6TBBcsATS4FaupUQH1TxUqadE8Dc=.40311ad5-ff24-46ab-ae2c-07b9d51fa8cc@github.com>
Message-ID: <NpfXZliHGUMoxRzmJ7maM4RSFCFEqjz7PlyDIexBxcc=.1a5e1f0b-db5c-4cca-8c13-cbe814109e3f@github.com>

On Mon, 7 Feb 2022 19:01:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing per review
>
> src/hotspot/share/interpreter/oopMapCache.cpp line 282:
> 
>> 280:   LogStream st(Log(interpreter, oopmap)::trace());
>> 281: 
>> 282:   if (log) st.print("Locals (%d): ", max_locals);
> 
> This seems unfortunate to have these if statements, and a counter goal of the logging framework.  Is there another way to do this without the if statements?

The problem is that here we use multiple print()/cr() statements to make up a single log message, thus we cannot simply use regular log_trace(). The only obvious way to avoid multiple if statements is to quote whole body with one if and introduce else branch without logging. But as I understand the intention of LogStream is exactly to combine a log message as a combination of pieces, so I don't see any problem here

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From coleenp at openjdk.java.net  Mon Feb  7 20:26:08 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 7 Feb 2022 20:26:08 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v2]
In-Reply-To: <NpfXZliHGUMoxRzmJ7maM4RSFCFEqjz7PlyDIexBxcc=.1a5e1f0b-db5c-4cca-8c13-cbe814109e3f@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <8QkcpGFEBANDKh9Tltd8svAJxLbApldFhwXLwvTeFDg=.70a2aca7-2afe-4a9e-b371-b27a52610a14@github.com>
 <eD4MrEM5W9DFhjP6TBBcsATS4FaupUQH1TxUqadE8Dc=.40311ad5-ff24-46ab-ae2c-07b9d51fa8cc@github.com>
 <NpfXZliHGUMoxRzmJ7maM4RSFCFEqjz7PlyDIexBxcc=.1a5e1f0b-db5c-4cca-8c13-cbe814109e3f@github.com>
Message-ID: <1Tn7iSGWkv9o9q02j06JFrCvMFajq8NUwVrw4aQBGDI=.44633b51-cfce-48e0-9826-b7462f71f7f6@github.com>

On Mon, 7 Feb 2022 19:35:12 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> src/hotspot/share/interpreter/oopMapCache.cpp line 282:
>> 
>>> 280:   LogStream st(Log(interpreter, oopmap)::trace());
>>> 281: 
>>> 282:   if (log) st.print("Locals (%d): ", max_locals);
>> 
>> This seems unfortunate to have these if statements, and a counter goal of the logging framework.  Is there another way to do this without the if statements?
>
> The problem is that here we use multiple print()/cr() statements to make up a single log message, thus we cannot simply use regular log_trace(). The only obvious way to avoid multiple if statements is to quote whole body with one if and introduce else branch without logging. But as I understand the intention of LogStream is exactly to build log message as a combination of pieces, so I don't see any problem here

The logging framework was intended to avoid these explicit if statements also.  It seems it could be refactored to duplicate the loops with logging, and not combine them with verification.

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From dholmes at openjdk.java.net  Tue Feb  8 02:30:08 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Feb 2022 02:30:08 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v2]
In-Reply-To: <1Tn7iSGWkv9o9q02j06JFrCvMFajq8NUwVrw4aQBGDI=.44633b51-cfce-48e0-9826-b7462f71f7f6@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <8QkcpGFEBANDKh9Tltd8svAJxLbApldFhwXLwvTeFDg=.70a2aca7-2afe-4a9e-b371-b27a52610a14@github.com>
 <eD4MrEM5W9DFhjP6TBBcsATS4FaupUQH1TxUqadE8Dc=.40311ad5-ff24-46ab-ae2c-07b9d51fa8cc@github.com>
 <NpfXZliHGUMoxRzmJ7maM4RSFCFEqjz7PlyDIexBxcc=.1a5e1f0b-db5c-4cca-8c13-cbe814109e3f@github.com>
 <1Tn7iSGWkv9o9q02j06JFrCvMFajq8NUwVrw4aQBGDI=.44633b51-cfce-48e0-9826-b7462f71f7f6@github.com>
Message-ID: <HqhaOe7qiWsGpA2wLle9Es8axX2Qn5mJUqhK60UdEao=.67fc71ec-0665-45fd-a9e0-d5399fc000a8@github.com>

On Mon, 7 Feb 2022 20:22:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The problem is that here we use multiple print()/cr() statements to make up a single log message, thus we cannot simply use regular log_trace(). The only obvious way to avoid multiple if statements is to quote whole body with one if and introduce else branch without logging. But as I understand the intention of LogStream is exactly to build log message as a combination of pieces, so I don't see any problem here
>
> The logging framework was intended to avoid these explicit if statements also.  It seems it could be refactored to duplicate the loops with logging, and not combine them with verification.

The logging framework was also supposed to not introduce overhead if logging is not enabled, but that is not the case as has been discovered here. I prefer the `if` statements to duplicating the code to have one block with logging and one without.

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From dholmes at openjdk.java.net  Tue Feb  8 02:43:07 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Feb 2022 02:43:07 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v3]
In-Reply-To: <vJGBkB9hZoArr_NJqj3x2kp03C6zgxT5iIuC3j01wx0=.fe6ddf04-c749-4154-b150-24241cacd4ac@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <vJGBkB9hZoArr_NJqj3x2kp03C6zgxT5iIuC3j01wx0=.fe6ddf04-c749-4154-b150-24241cacd4ac@github.com>
Message-ID: <rKyGzwsHfMnNXEYkIt34KjbSLZ4MhX4Gl_Y3RZP8WOY=.9724c7a5-8850-4961-be6b-de1743330f62@github.com>

On Mon, 7 Feb 2022 14:34:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
>> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust output again, adjust test

test/lib/jdk/test/lib/containers/docker/Common.java line 74:

> 72:     }
> 73: 
> 74:     public static DockerRunOptions newOpts(String imageNameAndTag, String testClass, String addJavaOpts) {

It would be good to avoid code duplication and just e.g. have the no-arg `newOpts` pass `null` for `addJavaOpts`.

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From duke at openjdk.java.net  Tue Feb  8 03:34:53 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Tue, 8 Feb 2022 03:34:53 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v2]
In-Reply-To: <HqhaOe7qiWsGpA2wLle9Es8axX2Qn5mJUqhK60UdEao=.67fc71ec-0665-45fd-a9e0-d5399fc000a8@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <8QkcpGFEBANDKh9Tltd8svAJxLbApldFhwXLwvTeFDg=.70a2aca7-2afe-4a9e-b371-b27a52610a14@github.com>
 <eD4MrEM5W9DFhjP6TBBcsATS4FaupUQH1TxUqadE8Dc=.40311ad5-ff24-46ab-ae2c-07b9d51fa8cc@github.com>
 <NpfXZliHGUMoxRzmJ7maM4RSFCFEqjz7PlyDIexBxcc=.1a5e1f0b-db5c-4cca-8c13-cbe814109e3f@github.com>
 <1Tn7iSGWkv9o9q02j06JFrCvMFajq8NUwVrw4aQBGDI=.44633b51-cfce-48e0-9826-b7462f71f7f6@github.com>
 <HqhaOe7qiWsGpA2wLle9Es8axX2Qn5mJUqhK60UdEao=.67fc71ec-0665-45fd-a9e0-d5399fc000a8@github.com>
Message-ID: <-TttVdjOHR1JwLiMTSt_LsPiyu8pYSvY8_cKJy5EyDc=.79fc2e5d-b331-4d7d-8f28-19f821d510b4@github.com>

On Tue, 8 Feb 2022 02:27:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The logging framework was intended to avoid these explicit if statements also.  It seems it could be refactored to duplicate the loops with logging, and not combine them with verification.
>
> The logging framework was also supposed to not introduce overhead if logging is not enabled, but that is not the case as has been discovered here. I prefer the `if` statements to duplicating the code to have one block with logging and one without.

fixed 34713cf

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Tue Feb  8 03:34:51 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Tue, 8 Feb 2022 03:34:51 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v3]
In-Reply-To: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
Message-ID: <2lBnzQx1gNPztCOsixzxZr5_yoxielUf25pM5kgvk2Q=.9b437e56-a286-4645-8538-9f6471f174ff@github.com>

> Fixes
> 
> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
> 
> eliminating frequent generation of log messages with no respect of logging configuration
> 
> Verification: N/A (the issue does not have an observable effect)
> 
> Regression: hotspot_compiler (20.04 on amd64 )

Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:

  Replacing multiple if statements with single one

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7367/files
  - new: https://git.openjdk.java.net/jdk/pull/7367/files/96b73adf..34713cf2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=01-02

  Stats: 19 lines in 1 file changed: 1 ins; 3 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7367.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7367/head:pull/7367

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Tue Feb  8 06:39:33 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Tue, 8 Feb 2022 06:39:33 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v4]
In-Reply-To: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
Message-ID: <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>

> Fixes
> 
> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
> 
> eliminating frequent generation of log messages with no respect of logging configuration
> 
> Verification: N/A (the issue does not have an observable effect)
> 
> Regression: hotspot_compiler (20.04 on amd64 )

Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:

  Restores mistakenly lost code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7367/files
  - new: https://git.openjdk.java.net/jdk/pull/7367/files/34713cf2..37d40eab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=02-03

  Stats: 16 lines in 1 file changed: 16 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7367.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7367/head:pull/7367

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Tue Feb  8 06:42:17 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Tue, 8 Feb 2022 06:42:17 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v3]
In-Reply-To: <2lBnzQx1gNPztCOsixzxZr5_yoxielUf25pM5kgvk2Q=.9b437e56-a286-4645-8538-9f6471f174ff@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <2lBnzQx1gNPztCOsixzxZr5_yoxielUf25pM5kgvk2Q=.9b437e56-a286-4645-8538-9f6471f174ff@github.com>
Message-ID: <BlJNuLTKlZoTgKceAFPJjC5m3AdkEaeYZXr2lFJPd20=.b3470005-1544-48ce-abd4-ebaebb46cd29@github.com>

On Tue, 8 Feb 2022 03:34:51 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replacing multiple if statements with single one

Sorry guys, I commited [34713cf](https://github.com/openjdk/jdk/pull/7367/commits/34713cf2619c594527022a6ac29ee55df8e61f97) in 6:00 AM, and it looks like I had not woken up yet

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From dholmes at openjdk.java.net  Tue Feb  8 07:16:09 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Feb 2022 07:16:09 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v4]
In-Reply-To: <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
Message-ID: <9FUuJgvgO8gL4TWm96XX_2AF-XNATsFDpJu6xKRsP58=.42c2084e-fa8e-4b2c-ab6f-252892ca79e9@github.com>

On Tue, 8 Feb 2022 06:39:33 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restores mistakenly lost code

Sorry but I really object to the code duplication here.

I guess we need a third opinion. :)

David

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7367

From shade at openjdk.java.net  Tue Feb  8 07:23:08 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Feb 2022 07:23:08 GMT
Subject: RFR: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers [v3]
In-Reply-To: <gek8UGdo1ECF2IzV9GdtDtcq4POCQycjup7B1UXPjBg=.97aa2aa9-3b06-4daf-b320-1ba9a39d5153@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
 <gek8UGdo1ECF2IzV9GdtDtcq4POCQycjup7B1UXPjBg=.97aa2aa9-3b06-4daf-b320-1ba9a39d5153@github.com>
Message-ID: <y0GTE4oOh4FPdClLHTmTPqv9Z8qdDD4cEs45fhmE6k0=.5e8b149d-c648-47e3-9403-eb2bda80a32b@github.com>

On Mon, 7 Feb 2022 16:09:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".
>> 
>> 
>>   product_pd(intx, StackYellowPages, \
>>           "Number of yellow zone (recoverable overflows) pages of size " \
>>           "4KB. If pages are bigger yellow zone is aligned up.") \
>>           range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
>> 
>> 
>> We can rename it for clarity.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

Thanks! The test failure in GHA is unrelated.

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From shade at openjdk.java.net  Tue Feb  8 07:23:09 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Feb 2022 07:23:09 GMT
Subject: Integrated: 8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages
 multipliers
In-Reply-To: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
References: <fwKIk-815lomWiJqJzQfdha9Q-b7YCWZWaxwaYUz7ug=.afcac163-4fd7-46e4-bc31-f10d353e0028@github.com>
Message-ID: <mwxP7D4ZJHeO8eywY7RPdKxM8ZqFSPhlOOaeLrX5km4=.f956482e-69e6-4ca2-8352-a03e2d57c51f@github.com>

On Mon, 7 Feb 2022 07:27:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This was a question during [JDK-8072070](https://bugs.openjdk.java.net/browse/JDK-8072070) review. The code in `StackOverflow::initialize_stack_zone_sizes()` multiplies `Stack{Red,Yellow,Reserved,Shadow}Pages` by "alignment", while that is actually just a "unit".
> 
> 
>   product_pd(intx, StackYellowPages, \
>           "Number of yellow zone (recoverable overflows) pages of size " \
>           "4KB. If pages are bigger yellow zone is aligned up.") \
>           range(MIN_STACK_YELLOW_PAGES, (DEFAULT_STACK_YELLOW_PAGES+5)) \
> 
> 
> We can rename it for clarity.

This pull request has now been integrated.

Changeset: 4eacacb5
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4eacacb5ad61020c11a521111c40af9fa72e2ff5
Stats:     9 lines in 1 file changed: 1 ins; 0 del; 8 mod

8281314: Rename Stack{Red,Yellow,Reserved,Shadow}Pages multipliers

Reviewed-by: stuefe, coleenp, xliu

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

PR: https://git.openjdk.java.net/jdk/pull/7362

From shade at openjdk.java.net  Tue Feb  8 07:28:12 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Feb 2022 07:28:12 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v4]
In-Reply-To: <9FUuJgvgO8gL4TWm96XX_2AF-XNATsFDpJu6xKRsP58=.42c2084e-fa8e-4b2c-ab6f-252892ca79e9@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
 <9FUuJgvgO8gL4TWm96XX_2AF-XNATsFDpJu6xKRsP58=.42c2084e-fa8e-4b2c-ab6f-252892ca79e9@github.com>
Message-ID: <snTF1JUCWo3u5NZniaRVf_vlGGkW2fe5eKWtAbjyCcE=.a9caad96-91da-455d-9bad-a452afb33f74@github.com>

On Tue, 8 Feb 2022 07:12:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but I really object to the code duplication here.

+1. I don't mind `if (log) { ... }` here, to be honest.

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Tue Feb  8 07:37:09 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Tue, 8 Feb 2022 07:37:09 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v4]
In-Reply-To: <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
Message-ID: <z2EYupBHI1gM3HaJM-bB2NLjB2oak5fthewbVaR3BY0=.96bc79fc-5f88-4596-82c2-a5ad03f6bcb5@github.com>

On Tue, 8 Feb 2022 06:39:33 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restores mistakenly lost code

I'd suggest to wrap `LogStream` with something like


struct tracer{
  tracer()
    : _enabled(log_is_enabled(LogLevel::Trace, interpreter, oopmap))
    , _stream(Log(interpreter, oopmap)::trace()) {
  }

  void print(const char* fmt, ...) {
    if (_enabled) {
      va_list args;
      va_start(args, format);
      _stream.print(fmt, args);
      va_end(args);
    }
  }

  void cr() {
    if (_enabled) _stream.cr();
  }

private:
  const bool _enabled;
  LogStream _stream;
};


but `LogStream.print()` requires `format` argument to be string literal. Also `outputStream::print()` and `outputStream::cr()` are not virtual, thus we cannot use dummy stream pointer to suppress logging

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From kbarrett at openjdk.java.net  Tue Feb  8 08:47:05 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 8 Feb 2022 08:47:05 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch [v2]
In-Reply-To: <Hd_LB2emf-eXFtm7JmSCA356VvH7_AT6F0r4ykAiGzk=.80f57442-3a8e-4ce3-bfd6-7058394a8463@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
 <MQejfQ16EQzKJp_4IiGts298qdKN4Ml2j3kaWBvG1q8=.7428c11c-5ead-4aac-b378-51f8e54b9855@github.com>
 <_02hc_OAvXGm0I9gsBw3OCHVnL9xx3B0CJyjzH5v82U=.86b2e230-1ceb-4592-86db-6786b4a35e41@github.com>
 <Hd_LB2emf-eXFtm7JmSCA356VvH7_AT6F0r4ykAiGzk=.80f57442-3a8e-4ce3-bfd6-7058394a8463@github.com>
Message-ID: <A1_RvHVZEs4vS821liFhm2lObcChcVR_kAujvtxwMZk=.86884ad8-7df3-433b-9a9c-9c00505dc037@github.com>

On Fri, 4 Feb 2022 16:17:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Also, that won't touch the last page when first page != last page, unless the last page is made exclusive, which calculation could also suffer from UB pointer arithmetic overflow.  Of course, the caller could suffer from that too; we can't so easily fix that.  Representing address ranges as [start, end) just generally suffers from that problem.
>
> All right, what irked me originally is that `cur == last` break assumes both `cur` and `last` are multiples of `page_size`, otherwise this loops "indefinitely" (until successive overflows help, I guess). This is true now, but it is not even asserted. Maybe it should be `cur >= last`?

I assumed that having both values be initialized as page-aligned just
before the loop made that obvious.

A slightly different way to write it might be:

void os::pretouch_memory(void* start, void* end, size_t page_size) {
  assert(start <= end, "invalid range: " PTR_FORMAT " -> " PTR_FORMAT, p2i(start), p2i(end));
  assert(is_power_of_2(page_size), "page size misaligned: %zu", page_size);
  assert(page_size >= sizeof(int), "page size too small: %zu", page_size);
  if (start < end) {
    // We're doing concurrent-safe touch and memory state has page
    // granularity, so we can touch anywhere in a page.  We need int
    // alignment for the touch.
    int* cur = static_cast<int*>(align_down(start, sizeof(int)));
    void* last = align_down(static_cast<char*>(end) - 1, page_size);
    assert(cur <= last, "invariant");
    // Iterate from first page through last (inclusive), being careful to
    // avoid overflow if the last page abuts the end of the address range.
    for ( ; true; cur += (page_size / sizeof(int))) {
      Atomic::add(cur, 0, memory_order_relaxed);
      if (cur >= last) break;
    }
  }
}

I don't know if you'd find that clearer.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From shade at openjdk.java.net  Tue Feb  8 08:53:10 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Feb 2022 08:53:10 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch [v2]
In-Reply-To: <A1_RvHVZEs4vS821liFhm2lObcChcVR_kAujvtxwMZk=.86884ad8-7df3-433b-9a9c-9c00505dc037@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
 <MQejfQ16EQzKJp_4IiGts298qdKN4Ml2j3kaWBvG1q8=.7428c11c-5ead-4aac-b378-51f8e54b9855@github.com>
 <_02hc_OAvXGm0I9gsBw3OCHVnL9xx3B0CJyjzH5v82U=.86b2e230-1ceb-4592-86db-6786b4a35e41@github.com>
 <Hd_LB2emf-eXFtm7JmSCA356VvH7_AT6F0r4ykAiGzk=.80f57442-3a8e-4ce3-bfd6-7058394a8463@github.com>
 <A1_RvHVZEs4vS821liFhm2lObcChcVR_kAujvtxwMZk=.86884ad8-7df3-433b-9a9c-9c00505dc037@github.com>
Message-ID: <X4r6HiXupsA9_RewIJrMC9V6O1SQ9cLb2aoajwO-oQs=.3add6586-cb6f-4b4e-b30e-653662fcd2fa@github.com>

On Tue, 8 Feb 2022 08:43:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> All right, what irked me originally is that `cur == last` break assumes both `cur` and `last` are multiples of `page_size`, otherwise this loops "indefinitely" (until successive overflows help, I guess). This is true now, but it is not even asserted. Maybe it should be `cur >= last`?
>
> I assumed that having both values be initialized as page-aligned just
> before the loop made that obvious.
> 
> A slightly different way to write it might be:
> 
> void os::pretouch_memory(void* start, void* end, size_t page_size) {
>   assert(start <= end, "invalid range: " PTR_FORMAT " -> " PTR_FORMAT, p2i(start), p2i(end));
>   assert(is_power_of_2(page_size), "page size misaligned: %zu", page_size);
>   assert(page_size >= sizeof(int), "page size too small: %zu", page_size);
>   if (start < end) {
>     // We're doing concurrent-safe touch and memory state has page
>     // granularity, so we can touch anywhere in a page.  We need int
>     // alignment for the touch.
>     int* cur = static_cast<int*>(align_down(start, sizeof(int)));
>     void* last = align_down(static_cast<char*>(end) - 1, page_size);
>     assert(cur <= last, "invariant");
>     // Iterate from first page through last (inclusive), being careful to
>     // avoid overflow if the last page abuts the end of the address range.
>     for ( ; true; cur += (page_size / sizeof(int))) {
>       Atomic::add(cur, 0, memory_order_relaxed);
>       if (cur >= last) break;
>     }
>   }
> }
> 
> I don't know if you'd find that clearer.

`int* cur` does not make it cleaner. I am fine with `align_down`-ing both `cur` and `last` to `page_size`, and then using `cur >= last` for extra safety. In other words, just change `==` to `>=` in the breaking condition.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From duke at openjdk.java.net  Tue Feb  8 08:45:04 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Tue, 8 Feb 2022 08:45:04 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v4]
In-Reply-To: <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
Message-ID: <AZ1VQ3o03vh_sHX9u8wyqbBmy1kxObIJxE4poUbMwUI=.513bfd31-2409-455f-886d-3eb23087f9de@github.com>

On Tue, 8 Feb 2022 06:39:33 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restores mistakenly lost code

Thus, we're going to leave [96b73ad](https://github.com/openjdk/jdk/pull/7367/commits/96b73adf7947c4538e915c81e798d267c602f80e), agree? Should I revert the later changes?

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From kbarrett at openjdk.java.net  Tue Feb  8 10:25:43 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 8 Feb 2022 10:25:43 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch [v3]
In-Reply-To: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
Message-ID: <3o6IaUW6rUnp7gwu4aAYZoqwhUzv8MwxLfNSH6sIrZs=.b21ec7d0-0d20-44d8-9515-f952cfefb9e7@github.com>

> [Trying again, after a couple previous proposals.]
> 
> Please review this change to os::pretouch_memory to permit use of the memory
> being pretouched concurrently with the pretouch operation.  This will allow
> future changes that can make use of such overlap.
> 
> Testing:
> mach5 tier1-3 with -XX:+AlwaysPreTouch.
> 
> Verified no performance impact by comparing startup times with Epsilon GC and
> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
> 
> None of these test concurrent use; that will wait for future changes that use
> the new feature.

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

  change loop termination test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7343/files
  - new: https://git.openjdk.java.net/jdk/pull/7343/files/a80ac44f..2e4e66a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7343&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7343&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From kbarrett at openjdk.java.net  Tue Feb  8 10:25:45 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 8 Feb 2022 10:25:45 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch [v3]
In-Reply-To: <X4r6HiXupsA9_RewIJrMC9V6O1SQ9cLb2aoajwO-oQs=.3add6586-cb6f-4b4e-b30e-653662fcd2fa@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <NrW4VIi9D0cbKYgPkUc9dY_3C1Q5XCe-Rsl-uwB7_zY=.c5ae0d40-4835-44e0-bb7d-a749fc5f3667@github.com>
 <MQejfQ16EQzKJp_4IiGts298qdKN4Ml2j3kaWBvG1q8=.7428c11c-5ead-4aac-b378-51f8e54b9855@github.com>
 <_02hc_OAvXGm0I9gsBw3OCHVnL9xx3B0CJyjzH5v82U=.86b2e230-1ceb-4592-86db-6786b4a35e41@github.com>
 <Hd_LB2emf-eXFtm7JmSCA356VvH7_AT6F0r4ykAiGzk=.80f57442-3a8e-4ce3-bfd6-7058394a8463@github.com>
 <A1_RvHVZEs4vS821liFhm2lObcChcVR_kAujvtxwMZk=.86884ad8-7df3-433b-9a9c-9c00505dc037@github.com>
 <X4r6HiXupsA9_RewIJrMC9V6O1SQ9cLb2aoajwO-oQs=.3add6586-cb6f-4b4e-b30e-653662fcd2fa@github.com>
Message-ID: <m2f60tuWH-5LYr_spgVw-yo7U6A__d7KZ62XhQRamfU=.19d3d5c6-1037-49bf-938f-ebc6c2641538@github.com>

On Tue, 8 Feb 2022 08:50:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I assumed that having both values be initialized as page-aligned just
>> before the loop made that obvious.
>> 
>> A slightly different way to write it might be:
>> 
>> void os::pretouch_memory(void* start, void* end, size_t page_size) {
>>   assert(start <= end, "invalid range: " PTR_FORMAT " -> " PTR_FORMAT, p2i(start), p2i(end));
>>   assert(is_power_of_2(page_size), "page size misaligned: %zu", page_size);
>>   assert(page_size >= sizeof(int), "page size too small: %zu", page_size);
>>   if (start < end) {
>>     // We're doing concurrent-safe touch and memory state has page
>>     // granularity, so we can touch anywhere in a page.  We need int
>>     // alignment for the touch.
>>     int* cur = static_cast<int*>(align_down(start, sizeof(int)));
>>     void* last = align_down(static_cast<char*>(end) - 1, page_size);
>>     assert(cur <= last, "invariant");
>>     // Iterate from first page through last (inclusive), being careful to
>>     // avoid overflow if the last page abuts the end of the address range.
>>     for ( ; true; cur += (page_size / sizeof(int))) {
>>       Atomic::add(cur, 0, memory_order_relaxed);
>>       if (cur >= last) break;
>>     }
>>   }
>> }
>> 
>> I don't know if you'd find that clearer.
>
> `int* cur` does not make it cleaner. I am fine with `align_down`-ing both `cur` and `last` to `page_size`, and then using `cur >= last` for extra safety. In other words, just change `==` to `>=` in the breaking condition.

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From shade at openjdk.java.net  Tue Feb  8 10:27:18 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Feb 2022 10:27:18 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch [v3]
In-Reply-To: <3o6IaUW6rUnp7gwu4aAYZoqwhUzv8MwxLfNSH6sIrZs=.b21ec7d0-0d20-44d8-9515-f952cfefb9e7@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <3o6IaUW6rUnp7gwu4aAYZoqwhUzv8MwxLfNSH6sIrZs=.b21ec7d0-0d20-44d8-9515-f952cfefb9e7@github.com>
Message-ID: <6hR6yKnsv2m5IwerkwbMcrRVTf7v1GCFqwKB7VVL17s=.cc3edef0-04a1-4076-aa8b-f51e2aefba76@github.com>

On Tue, 8 Feb 2022 10:25:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> [Trying again, after a couple previous proposals.]
>> 
>> Please review this change to os::pretouch_memory to permit use of the memory
>> being pretouched concurrently with the pretouch operation.  This will allow
>> future changes that can make use of such overlap.
>> 
>> Testing:
>> mach5 tier1-3 with -XX:+AlwaysPreTouch.
>> 
>> Verified no performance impact by comparing startup times with Epsilon GC and
>> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
>> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
>> 
>> None of these test concurrent use; that will wait for future changes that use
>> the new feature.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change loop termination test

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From thartmann at openjdk.java.net  Tue Feb  8 10:36:11 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Feb 2022 10:36:11 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <fjeTf7oDUQ9aCFpzmQltU0pTCcsdPRFlbPZEBWzb7tI=.9d78eaf3-ef7e-466b-97a6-12dff9c280b7@github.com>

On Tue, 1 Feb 2022 19:09:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
> 
> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
> 
> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
> 
> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
> 
> Testing: hs-tier1 - hs-tier6

Looks reasonable to me.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7314

From stuefe at openjdk.java.net  Tue Feb  8 12:20:26 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 8 Feb 2022 12:20:26 GMT
Subject: RFR: JDK-8281450: Remove unnecessary operator new and delete from
 ObjectMonitor
Message-ID: <tlPg_9ZYUQ5icU40ORegEt4gfjhJ3utm_tnAskMmwOE=.bd18d5f0-b315-40a3-b3a2-afcbdb5d4607@github.com>

Trivial (?) patch to remove ObjectMonitor operator new and delete. Since ObjectMonitor derives from CHeapObj, we don't need those. 

This also solves the problem that the local new overrules the NMT category flag set in CHeapObj (both currently are mtInternal, so the problem is theoretical).

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

Commit messages:
 - update copyright
 - remove ObjMon new and delete

Changes: https://git.openjdk.java.net/jdk/pull/7377/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7377&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281450
  Stats: 20 lines in 2 files changed: 0 ins; 18 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7377.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7377/head:pull/7377

PR: https://git.openjdk.java.net/jdk/pull/7377

From dholmes at openjdk.java.net  Tue Feb  8 13:01:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Feb 2022 13:01:05 GMT
Subject: RFR: JDK-8281450: Remove unnecessary operator new and delete from
 ObjectMonitor
In-Reply-To: <tlPg_9ZYUQ5icU40ORegEt4gfjhJ3utm_tnAskMmwOE=.bd18d5f0-b315-40a3-b3a2-afcbdb5d4607@github.com>
References: <tlPg_9ZYUQ5icU40ORegEt4gfjhJ3utm_tnAskMmwOE=.bd18d5f0-b315-40a3-b3a2-afcbdb5d4607@github.com>
Message-ID: <F2OabN5sYqeuOgtTQN_h1hbgs4BElq12AYbe-mwQv3w=.ea5bae2c-d845-409a-a666-a8ca75f725cc@github.com>

On Tue, 8 Feb 2022 08:03:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial (?) patch to remove ObjectMonitor operator new and delete. Since ObjectMonitor derives from CHeapObj, we don't need those. 
> 
> This also solves the problem that the local new overrules the NMT category flag set in CHeapObj (both currently are mtInternal, so the problem is theoretical).

Hi Thomas,

Initially I was a bit confused as I found the ADLC definition of CHeapObj :) But now I see this is a trivial cleanup.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7377

From stuefe at openjdk.java.net  Tue Feb  8 13:09:10 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 8 Feb 2022 13:09:10 GMT
Subject: RFR: JDK-8281450: Remove unnecessary operator new and delete from
 ObjectMonitor
In-Reply-To: <F2OabN5sYqeuOgtTQN_h1hbgs4BElq12AYbe-mwQv3w=.ea5bae2c-d845-409a-a666-a8ca75f725cc@github.com>
References: <tlPg_9ZYUQ5icU40ORegEt4gfjhJ3utm_tnAskMmwOE=.bd18d5f0-b315-40a3-b3a2-afcbdb5d4607@github.com>
 <F2OabN5sYqeuOgtTQN_h1hbgs4BElq12AYbe-mwQv3w=.ea5bae2c-d845-409a-a666-a8ca75f725cc@github.com>
Message-ID: <6CH0ZgmFy9UK28erLU4HKW_uSGtVNVEhdxN6lfz9TG8=.5d6dd4b7-2b30-4252-9308-cfd9f7e21ed7@github.com>

On Tue, 8 Feb 2022 12:58:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Thomas,
> 
> Initially I was a bit confused as I found the ADLC definition of CHeapObj :) But now I see this is a trivial cleanup.
> 
> Thanks, David

:-) I keep having this problem with our Arena code. Reminds me that I wanted to ask Vladimir K whether it's ok to rename the ADLC versions...

Thanks for the thumbs up!

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

PR: https://git.openjdk.java.net/jdk/pull/7377

From stuefe at openjdk.java.net  Tue Feb  8 14:41:04 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 8 Feb 2022 14:41:04 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch [v3]
In-Reply-To: <3o6IaUW6rUnp7gwu4aAYZoqwhUzv8MwxLfNSH6sIrZs=.b21ec7d0-0d20-44d8-9515-f952cfefb9e7@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <3o6IaUW6rUnp7gwu4aAYZoqwhUzv8MwxLfNSH6sIrZs=.b21ec7d0-0d20-44d8-9515-f952cfefb9e7@github.com>
Message-ID: <Cly_UHmqsfoxLc8pavYpQgWh0jh0sm9hRftlGSM7BIU=.a595cd42-9657-4cd4-9709-d672673a2fc3@github.com>

On Tue, 8 Feb 2022 10:25:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> [Trying again, after a couple previous proposals.]
>> 
>> Please review this change to os::pretouch_memory to permit use of the memory
>> being pretouched concurrently with the pretouch operation.  This will allow
>> future changes that can make use of such overlap.
>> 
>> Testing:
>> mach5 tier1-3 with -XX:+AlwaysPreTouch.
>> 
>> Verified no performance impact by comparing startup times with Epsilon GC and
>> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
>> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
>> 
>> None of these test concurrent use; that will wait for future changes that use
>> the new feature.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change loop termination test

looks still good.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From stuefe at openjdk.java.net  Tue Feb  8 14:47:07 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 8 Feb 2022 14:47:07 GMT
Subject: Integrated: JDK-8281450: Remove unnecessary operator new and delete
 from ObjectMonitor
In-Reply-To: <tlPg_9ZYUQ5icU40ORegEt4gfjhJ3utm_tnAskMmwOE=.bd18d5f0-b315-40a3-b3a2-afcbdb5d4607@github.com>
References: <tlPg_9ZYUQ5icU40ORegEt4gfjhJ3utm_tnAskMmwOE=.bd18d5f0-b315-40a3-b3a2-afcbdb5d4607@github.com>
Message-ID: <h_3nx-vjtMdRYPl-oJwtSzZNjKzBBAz_t2mFLgU8YFc=.a4e237b5-010c-4524-81e7-2ec989d889f5@github.com>

On Tue, 8 Feb 2022 08:03:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial (?) patch to remove ObjectMonitor operator new and delete. Since ObjectMonitor derives from CHeapObj, we don't need those. 
> 
> This also solves the problem that the local new overrules the NMT category flag set in CHeapObj (both currently are mtInternal, so the problem is theoretical).

This pull request has now been integrated.

Changeset: 83d67452
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/83d67452da248db17bc72de80247a670d6813cf5
Stats:     20 lines in 2 files changed: 0 ins; 18 del; 2 mod

8281450: Remove unnecessary operator new and delete from ObjectMonitor

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/7377

From stuefe at openjdk.java.net  Tue Feb  8 14:50:24 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 8 Feb 2022 14:50:24 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
Message-ID: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>

It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.

Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

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

Commit messages:
 - mtObjectMonitor

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From vlivanov at openjdk.java.net  Tue Feb  8 14:55:53 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 8 Feb 2022 14:55:53 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported [v2]
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <zkLhmbUpSp4oh5DjiboABU1c8tyLSL1WsDuHD7m_MlQ=.526f94a8-ae4e-4157-b2e2-26c53d9037ed@github.com>

> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
> 
> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
> 
> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
> 
> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
> 
> Testing: hs-tier1 - hs-tier6

Vladimir Ivanov 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:

 - fatal -> assert
 - Merge branch 'master' into 8279822.cpe_in_error
 - Compiler support of CP entries in error state

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7314/files
  - new: https://git.openjdk.java.net/jdk/pull/7314/files/b6cc375c..9bdf70ff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7314&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7314&range=00-01

  Stats: 4160 lines in 186 files changed: 3210 ins; 452 del; 498 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7314.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7314/head:pull/7314

PR: https://git.openjdk.java.net/jdk/pull/7314

From mbaesken at openjdk.java.net  Tue Feb  8 15:21:37 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 8 Feb 2022 15:21:37 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v4]
In-Reply-To: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
Message-ID: <AmZTNV4hm7z0gDQl6V_GuiSz30io0u9KWaR9rpL3NHI=.8b4efe37-941b-440e-9e62-82f4ac08eb46@github.com>

> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.

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

  Add separate testPrintContainerInfoActiveProcessorCount, avoid code duplication in Common

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7354/files
  - new: https://git.openjdk.java.net/jdk/pull/7354/files/52fee02c..29352421

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7354&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7354&range=02-03

  Stats: 20 lines in 2 files changed: 11 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7354/head:pull/7354

PR: https://git.openjdk.java.net/jdk/pull/7354

From mbaesken at openjdk.java.net  Tue Feb  8 15:21:39 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 8 Feb 2022 15:21:39 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v3]
In-Reply-To: <vJGBkB9hZoArr_NJqj3x2kp03C6zgxT5iIuC3j01wx0=.fe6ddf04-c749-4154-b150-24241cacd4ac@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <vJGBkB9hZoArr_NJqj3x2kp03C6zgxT5iIuC3j01wx0=.fe6ddf04-c749-4154-b150-24241cacd4ac@github.com>
Message-ID: <u5zKCTcWSaPZvEZ0qWYMRXIxSFO__6_NirqThnrvZ-k=.2a87d553-5361-4535-b644-85eefdad8472@github.com>

On Mon, 7 Feb 2022 14:34:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
>> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust output again, adjust test

Hi David and Severin, I added a separate test to TestMisc.  Additionally I adjusted Common.java to avoid code duplication.
Thanks, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From amenkov at openjdk.java.net  Tue Feb  8 16:55:42 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 8 Feb 2022 16:55:42 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times
Message-ID: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>

ClassLoaderDataGraph::classes_do description says:
// Walking classes through the ClassLoaderDataGraph include array classes.
So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)

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

Commit messages:
 - JDK-8281267

Changes: https://git.openjdk.java.net/jdk/pull/7384/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281267
  Stats: 361 lines in 2 files changed: 338 ins; 10 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7384.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7384/head:pull/7384

PR: https://git.openjdk.java.net/jdk/pull/7384

From shade at openjdk.java.net  Tue Feb  8 17:25:11 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Feb 2022 17:25:11 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v4]
In-Reply-To: <AZ1VQ3o03vh_sHX9u8wyqbBmy1kxObIJxE4poUbMwUI=.513bfd31-2409-455f-886d-3eb23087f9de@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
 <AZ1VQ3o03vh_sHX9u8wyqbBmy1kxObIJxE4poUbMwUI=.513bfd31-2409-455f-886d-3eb23087f9de@github.com>
Message-ID: <9mnsdNf6SmL1gnIU3uETidBRq0MjxIByMwxfJJd28YA=.fe1a7c8e-a98c-4e72-be0d-48b7996dfc35@github.com>

On Tue, 8 Feb 2022 08:41:53 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> 



> Thus, we're going to leave [96b73ad](https://github.com/openjdk/jdk/pull/7367/commits/96b73adf7947c4538e915c81e798d267c602f80e), right? Should I revert the later changes?

Yes, https://github.com/openjdk/jdk/pull/7367/commits/96b73adf7947c4538e915c81e798d267c602f80e looks acceptable to me. Let's ask @dholmes-ora if he's good with it too.

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From sgehwolf at openjdk.java.net  Tue Feb  8 17:35:10 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 8 Feb 2022 17:35:10 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v4]
In-Reply-To: <AmZTNV4hm7z0gDQl6V_GuiSz30io0u9KWaR9rpL3NHI=.8b4efe37-941b-440e-9e62-82f4ac08eb46@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <AmZTNV4hm7z0gDQl6V_GuiSz30io0u9KWaR9rpL3NHI=.8b4efe37-941b-440e-9e62-82f4ac08eb46@github.com>
Message-ID: <Ry31qF_OPoBTXX0OmMhLYg4L3EN5Nu56VcuRdnX5JmQ=.0b08c313-13b7-4160-bb33-a8ea07983b1f@github.com>

On Tue, 8 Feb 2022 15:21:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
>> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add separate testPrintContainerInfoActiveProcessorCount, avoid code duplication in Common

Changes requested by sgehwolf (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From sgehwolf at openjdk.java.net  Tue Feb  8 17:35:11 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 8 Feb 2022 17:35:11 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v3]
In-Reply-To: <chd2Kv8UoKu1Z_e8Jgfn7_ceKXbas5I5lj2hJfHlQRk=.7f6f4b4a-f7aa-4adb-83e9-65e6dea26306@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <vJGBkB9hZoArr_NJqj3x2kp03C6zgxT5iIuC3j01wx0=.fe6ddf04-c749-4154-b150-24241cacd4ac@github.com>
 <chd2Kv8UoKu1Z_e8Jgfn7_ceKXbas5I5lj2hJfHlQRk=.7f6f4b4a-f7aa-4adb-83e9-65e6dea26306@github.com>
Message-ID: <hFAaJLHgxOZqixfmjpYeeSuUELuwQS0z3WuQ8w5DNEs=.78e05879-d45a-4f68-99d9-5a7ee5f6b714@github.com>

On Mon, 7 Feb 2022 16:15:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust output again, adjust test
>
> test/hotspot/jtreg/containers/docker/TestMisc.java line 89:
> 
>> 87:         Common.logNewTestCase("Test print_container_info()");
>> 88: 
>> 89:         DockerRunOptions opts = Common.newOpts(imageName, "PrintContainerInfo", "-XX:ActiveProcessorCount=2");
> 
> It would be better to separate this specific test. More like this:
> https://github.com/jerboaa/jdk/commit/3911ef81c8f280a2c0da259211b91f4c3e8c3994

I'm not sure I like this version of the test better. I'd rather separate concerns. The changes to `Common` aren't really needed, as `Common.newOpts(imageName, "PrintContainerInfo").addJavaOpts("-XX:ActiveProcessorCount=2");` can be used instead. Similarly, the changes to `checkContainerInfo()` make the test harder to read. It's once called with a `null` argument and checks similar things, but one additional assert. Rather than that, I'd just do the assert directly in the new test as suggested. This saves the reader having to look up call-sites to know what the test is actually asserting. This also more closely matches what's likely to happen in real scenarios (override the container detection heuristics with `-XX:ActiveProcessorCount`).

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From iklam at openjdk.java.net  Tue Feb  8 18:53:09 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 8 Feb 2022 18:53:09 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v4]
In-Reply-To: <AmZTNV4hm7z0gDQl6V_GuiSz30io0u9KWaR9rpL3NHI=.8b4efe37-941b-440e-9e62-82f4ac08eb46@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <AmZTNV4hm7z0gDQl6V_GuiSz30io0u9KWaR9rpL3NHI=.8b4efe37-941b-440e-9e62-82f4ac08eb46@github.com>
Message-ID: <jC7H3EtBMlk1hN3BlrDa46GN82sKha5iilxzBaykTS0=.ad5e3ff9-a9aa-4ab5-bc41-f1304208f4f5@github.com>

On Tue, 8 Feb 2022 15:21:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
>> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add separate testPrintContainerInfoActiveProcessorCount, avoid code duplication in Common

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7354

From dcubed at openjdk.java.net  Tue Feb  8 20:20:23 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 8 Feb 2022 20:20:23 GMT
Subject: Integrated: 8281476: ProblemList
 tools/jar/CreateMissingParentDirectories.java
Message-ID: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>

A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java.

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

Commit messages:
 - 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java

Changes: https://git.openjdk.java.net/jdk/pull/7390/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7390&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281476
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7390.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7390/head:pull/7390

PR: https://git.openjdk.java.net/jdk/pull/7390

From azvegint at openjdk.java.net  Tue Feb  8 20:20:23 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 8 Feb 2022 20:20:23 GMT
Subject: Integrated: 8281476: ProblemList
 tools/jar/CreateMissingParentDirectories.java
In-Reply-To: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>
References: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>
Message-ID: <OZ4wr68RNlUbnHoW383stedqC-E1rlDDjhiKImRNvQ4=.e2197614-1abb-4d5e-a630-36c3fb71a833@github.com>

On Tue, 8 Feb 2022 20:09:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7390

From bpb at openjdk.java.net  Tue Feb  8 20:20:24 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 8 Feb 2022 20:20:24 GMT
Subject: Integrated: 8281476: ProblemList
 tools/jar/CreateMissingParentDirectories.java
In-Reply-To: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>
References: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>
Message-ID: <tZfv_CpdwAWa1sg0Ty2WpudzVHWBIylJivftI90d1LI=.37b6bfca-6c05-4594-942b-63fbe2dad522@github.com>

On Tue, 8 Feb 2022 20:09:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7390

From lancea at openjdk.java.net  Tue Feb  8 20:20:24 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 8 Feb 2022 20:20:24 GMT
Subject: Integrated: 8281476: ProblemList
 tools/jar/CreateMissingParentDirectories.java
In-Reply-To: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>
References: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>
Message-ID: <sj26zadfTyRCiNqo_lRNSrINR76eT3GrS--WC5MhDgU=.c3b9bcc5-3b80-4ca6-b938-d3b665e2d978@github.com>

On Tue, 8 Feb 2022 20:09:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7390

From dcubed at openjdk.java.net  Tue Feb  8 20:20:24 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 8 Feb 2022 20:20:24 GMT
Subject: Integrated: 8281476: ProblemList
 tools/jar/CreateMissingParentDirectories.java
In-Reply-To: <OZ4wr68RNlUbnHoW383stedqC-E1rlDDjhiKImRNvQ4=.e2197614-1abb-4d5e-a630-36c3fb71a833@github.com>
References: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>
 <OZ4wr68RNlUbnHoW383stedqC-E1rlDDjhiKImRNvQ4=.e2197614-1abb-4d5e-a630-36c3fb71a833@github.com>
Message-ID: <bdFahWY_lXEQWtgxfBezqPZFZF3_P_DUrGdEX-WF2cQ=.31a44824-5267-4bf5-ba24-04e1242fe8e8@github.com>

On Tue, 8 Feb 2022 20:10:38 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java.
>
> Marked as reviewed by azvegint (Reviewer).

@azvegint and @bplb - Thanks for the lightning fast reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/7390

From dcubed at openjdk.java.net  Tue Feb  8 20:20:24 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 8 Feb 2022 20:20:24 GMT
Subject: Integrated: 8281476: ProblemList
 tools/jar/CreateMissingParentDirectories.java
In-Reply-To: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>
References: <dehkmDERXvmfD83TDw4muo98Ur8rR1Ttqzl_gJ1vnX8=.03e4a74a-4f5f-4a9f-ba9c-2f8013bb8440@github.com>
Message-ID: <TUy_PDgzJfUR5Ug_iZupY024jdv-0DABtAXAfYKF5YI=.c3315915-5059-4130-94ec-ecb8a1f2d432@github.com>

On Tue, 8 Feb 2022 20:09:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java.

This pull request has now been integrated.

Changeset: 5fb56dbb
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5fb56dbb0b4e3345ca6f48ba9c01bd467f04aa6f
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8281476: ProblemList tools/jar/CreateMissingParentDirectories.java

Reviewed-by: azvegint, bpb, lancea

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

PR: https://git.openjdk.java.net/jdk/pull/7390

From dholmes at openjdk.java.net  Wed Feb  9 00:50:13 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Feb 2022 00:50:13 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v4]
In-Reply-To: <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <25KzeOsc2GYRy45fv2o0r8NLlrNTOuBw5TJ6X89n8kw=.e23526e6-a29a-4a7e-8001-5da8d077044d@github.com>
Message-ID: <8k8WE4RO78EhjSPqrR_rWjcCCoOx8mi3jvWv-Qq3jnw=.18804773-23d4-4ff3-8cf0-be3432c867b2@github.com>

On Tue, 8 Feb 2022 06:39:33 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restores mistakenly lost code

Yes, https://github.com/openjdk/jdk/commit/96b73adf7947c4538e915c81e798d267c602f80e is the version I prefer.

Thanks,
David

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From dholmes at openjdk.java.net  Wed Feb  9 01:49:07 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Feb 2022 01:49:07 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <6qXMWvupAWu4HJYspeRPjryyAIPM2rpqMJhZ9EEEgfE=.5a18c014-c4db-4725-afeb-1f8564ba0c6d@github.com>

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

Hi Thomas,

Looks fine as far as it goes, but leads me to wonder about related data structures e.g. `ObjectMonitorsHashtable`, which seems to use `mtThread`. ??

Thanks,
David

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From duke at openjdk.java.net  Wed Feb  9 03:45:47 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Wed, 9 Feb 2022 03:45:47 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v5]
In-Reply-To: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
Message-ID: <KFc5tuJNSC7VtkGhJz6DN9jzcJnStWdNkHX7bEcAAHk=.bc10de29-3ed8-4bfa-9b53-4898d07897ac@github.com>

> Fixes
> 
> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
> 
> eliminating frequent generation of log messages with no respect of logging configuration
> 
> Verification: N/A (the issue does not have an observable effect)
> 
> Regression: hotspot_compiler (20.04 on amd64 )

Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Replacing multiple if statements with single one"
  
  This reverts commit 34713cf2619c594527022a6ac29ee55df8e61f97.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7367/files
  - new: https://git.openjdk.java.net/jdk/pull/7367/files/37d40eab..684ee0dd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=03-04

  Stats: 33 lines in 1 file changed: 1 ins; 15 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7367.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7367/head:pull/7367

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Wed Feb  9 03:50:04 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Wed, 9 Feb 2022 03:50:04 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v5]
In-Reply-To: <KFc5tuJNSC7VtkGhJz6DN9jzcJnStWdNkHX7bEcAAHk=.bc10de29-3ed8-4bfa-9b53-4898d07897ac@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <KFc5tuJNSC7VtkGhJz6DN9jzcJnStWdNkHX7bEcAAHk=.bc10de29-3ed8-4bfa-9b53-4898d07897ac@github.com>
Message-ID: <6g_ZgLnnWaKhzXFVbmgsCTIlkQNP21549ApBkBy-8VY=.31e45aa5-e676-4bb2-b29d-6bf5017affe8@github.com>

On Wed, 9 Feb 2022 03:45:47 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Replacing multiple if statements with single one"
>   
>   This reverts commit 34713cf2619c594527022a6ac29ee55df8e61f97.

done

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From stuefe at openjdk.java.net  Wed Feb  9 05:38:11 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Feb 2022 05:38:11 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <6qXMWvupAWu4HJYspeRPjryyAIPM2rpqMJhZ9EEEgfE=.5a18c014-c4db-4725-afeb-1f8564ba0c6d@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
 <6qXMWvupAWu4HJYspeRPjryyAIPM2rpqMJhZ9EEEgfE=.5a18c014-c4db-4725-afeb-1f8564ba0c6d@github.com>
Message-ID: <53Nru1H58-Iu37uYGpC88TuL03N_D7P4EuTcTruHwVE=.3aa968be-b82f-4c4f-bdb7-cc3c01c72031@github.com>

On Wed, 9 Feb 2022 01:45:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Thomas,
> 
> Looks fine as far as it goes, but leads me to wonder about related data structures e.g. `ObjectMonitorsHashtable`, which seems to use `mtThread`. ??
> 
> Thanks, David

Hi David,

my intent was specifically to get a look at the number of outstanding ObjectMonitor instances. Do you think I am misusing NMT here? If yes, I'm fine with withdrawing the PR.

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From shade at openjdk.java.net  Wed Feb  9 06:31:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 9 Feb 2022 06:31:06 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v5]
In-Reply-To: <KFc5tuJNSC7VtkGhJz6DN9jzcJnStWdNkHX7bEcAAHk=.bc10de29-3ed8-4bfa-9b53-4898d07897ac@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <KFc5tuJNSC7VtkGhJz6DN9jzcJnStWdNkHX7bEcAAHk=.bc10de29-3ed8-4bfa-9b53-4898d07897ac@github.com>
Message-ID: <AaXkkk4Hy9sIz-8IEocxGd93yA9u4eoyLckR2Xwrl9g=.bb593bc2-eaad-4238-8657-e54bc6db73ed@github.com>

On Wed, 9 Feb 2022 03:45:47 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Replacing multiple if statements with single one"
>   
>   This reverts commit 34713cf2619c594527022a6ac29ee55df8e61f97.

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From thomas.stuefe at gmail.com  Wed Feb  9 06:34:16 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 9 Feb 2022 07:34:16 +0100
Subject: Small question about JDK-8253064 and ObjectMonitor allocation
In-Reply-To: <c46874ee-2d6e-81ec-ea86-c88461e89d76@oracle.com>
References: <CAA-vtUx=3=cWGO-EXdVo23Os+c+CeBbbcuL+iA=7_b_W3TH0QQ@mail.gmail.com>
 <236484d3-0638-30d8-72dd-4dd3ce6e134a@oracle.com>
 <CAA-vtUwEgm4te2H4W=EoOry6ww5rZnn6Ty_hfAs1zg-AFc1AYQ@mail.gmail.com>
 <ad836150-899b-459e-8b30-1ddb0c173064@oracle.com>
 <CAA-vtUwOAPo1OFj=T-KhFDSe5VAdR+NjT0PFeuvLVx6dg72MQw@mail.gmail.com>
 <c46874ee-2d6e-81ec-ea86-c88461e89d76@oracle.com>
Message-ID: <CAA-vtUzJ2CgXm4a2BBeOWUWXcDhoNdvfe9pOOmR4CNoFTkh0cA@mail.gmail.com>

Hi,

I wonder if I understand this correctly:

- Monitors are only deflated by the MonitorDeflationThread, if I ignore
races on inflation
- The MonitorDeflationThread processes them in intervals of 250ms
(AsyncDeflationInterval), but only if there are more than 90
(MonitorUsedDeflationThreshold) monitors in use, and only in bulks of 1mio
(MonitorDeflationMax).

Is there any upward bound preventing the creation of ObjectMonitors, since
creation races with this one thread, and we also cap its ability to process
more than 1mio?

The background of my question is that I try to get a feel for the maximum
number of live monitors. When running renaissance philosophers benchmark I
see that the VM has, depending on machine speed and optimization level, >
2.5 million live ObjectMonitors, taking > 400MB heap space. Is this by
design?

The annoying thing is that these peaks in C-heap usage can be sticky,
depending on libc implementation. The glibc especially has poor reclaim
behavior. Also, it is hidden in NMT under "mtInternal", which is why I
propose to at least give it its own category (
https://bugs.openjdk.java.net/browse/JDK-8281450).

Thanks, Thomas

On Mon, Jan 31, 2022 at 11:59 PM <daniel.daugherty at oracle.com> wrote:

> Greetings,
>
> I'm going to try and add some historical context here...
>
>
> On 1/31/22 3:09 AM, Thomas St?fe wrote:
> > Thanks a lot for your answers, David.
>
> Yes David, thanks for jumping in on this thread.
>
>
> > On Mon, Jan 31, 2022 at 8:35 AM David Holmes <david.holmes at oracle.com>
> > wrote:
> >
> >> On 31/01/2022 3:54 pm, Thomas St?fe wrote:
> >>> Hi David,
> >>>
> >>> Thank you for the answer!
> >>>
> >>> On Mon, Jan 31, 2022 at 6:23 AM David Holmes <david.holmes at oracle.com
> >>> <mailto:david.holmes at oracle.com>> wrote:
> >>>
> >>>      Hi Thomas,
> >>>
> >>>      On 31/01/2022 2:32 pm, Thomas St?fe wrote:
> >>>       > Hi,
> >>>       >
> >>>       > I have a small question about a detail of JDK-8253064.
> >>>       >
> >>>       > IIUC, before this patch, the VM kept thread-local freelists of
> >>>       > pre-allocated ObjectMonitors to reduce allocation contention.
> Now we just
> >>>       > malloc monitors right away.
> >>>       >
> >>>       > I looked through the issue and the associated PR, but could
> find no
> >>>       > information on why this was done. Dan describes what he did
> very well:
> >>>       > https://github.com/openjdk/jdk/pull/642#issuecomment-720753946,
> but not
> >>>       > why.
>
> Thank you and I'm sorry that my words on 8253064 did not explain the why.
>
>
> >>>       > I assume that the complexity and memory overhead of the free
> lists was not
> >>>       > worth it? That you found that malloc() is on our platforms
> "uncontented"
> >>>       > enough?
> >>>
> >>>      The issue was not about freelists and contention it was about
> requiring
> >>>      type-stable-memory: that once a piece of memory was allocated as
> an
> >>>      ObjectMonitor it remained forever after an ObjectMonitor. This
> allowed
> >>>      for various race conditions in the old monitor code maintaining
> safety.
>
> Erik Osterlund did have some specific reasons for getting rid of
> type-stable-memory.
> At least on reason was that it was complicating the work he wanted to do
> on:
>
>      JDK-8247281 migrate ObjectMonitor::_object to OopStorage
>      https://bugs.openjdk.java.net/browse/JDK-8247281
>
> He and I did work together to split this work into the various pieces that
> were integrated separately. So TSM didn't prevent work on JDK-8247281, but
> it did make it more difficult.
>
> Erik may have had other reasons for getting rid of TSM. I've added him to
> this email thread directly so he has a better chance of seeing this query.
>
>
>
> >>>      Over time that code changed substantially and the need for
> >>>      type-stable-memory for ObjectMonitors disappeared, so we finally
> got rid
> >>>      of it and just moved to a direct allocation scheme.
> >>>
> >>>
> >>> I think I understand, but I was specifically concerned with the
> question
> >>> of allocation contention of ObjectMonitors. That is somewhat
> independent
> >>> from the question of where OMs are allocated.
> >>>
> >>> Can it happen that lock inflation happens clustered, or does that not
> >>> occur in reality?
> >>>
> >>> AFAIU the old code managed OM storage itself, used global data
> >>> structures to do so, and guarded access with a mutex. To reduce
> >>> contention, it used a surprisingly large thread-local freelist of 1024
> >>> entries. This looks like contention was once a real problem.
>
> We need to take a step back and look at how we got where we are. There
> are (at least) four different evolutions or seismic events to this
> subsystem:
>
> 1) type-stable-memory and the global lists (block and free)
>    - JDK-5030359 "Back-end" synchronization improvements for 1.5.1 or 1.6
>      https://bugs.openjdk.java.net/browse/JDK-5030359
>    - integrated in jdk-6+50 (partial), jdk-6+53 (finished)
>
>    - This integration introduced type-stable-memory (TSM) and global block
>      and free-lists. Dice chose to not use malloc and use TSM for a few
>      reasons:
>      - direct control of the placement of the ObjectMonitor on a cache-line
>        boundary; couldn't trust malloc to keep memory properly aligned.
>      - malloc was slower than direct management of blocks of
> ObjectMonitors.
>      - Dice did lots of benchmarking to prove the new code was faster in
>        things we cared about at the time on the platforms we cared about.
>    - This predates my joining the Runtime team so I don't have exhaustive
>      records on this work.
>
> 2a) per-thread free list
>    - JDK-6468954 Generic synchronization cleanups for J2SE 1.7
>      https://bugs.openjdk.java.net/browse/JDK-6468954
>    - integrated in jdk-7+12
>
>    - This integration introduced the per-thread free list. This addition
>      was to deal with contention with allocating an ObjectMonitor from
>      the global free-list.
>    - Again, Dice did targeted benchmarking to show that adding a per-thread
>      free list  performed better for some specific platforms/configs.
>    - This predates my joining the Runtime team so I don't have exhaustive
>      records on this work.
>
> 2b) per-thread in-use list
>    - JDK-6852873 Increase in delta between application stopped time and
> ParNew GC time over application lifetime
>      https://bugs.openjdk.java.net/browse/JDK-6852873
>    - integrated in jdk-7+99
>
>    - This integration added the MonitorInUseLists concept and was done
>      as part of some work to deal with a safepoint performance problem.
>    - MonitorInUseLists was disabled by default.
>    - The benchmarking done here was focused on safepointing.
>    - I joined the Runtime team in Jan 2010, but I don't have exhaustive
>      records on this work.
>
> 2c) global in-use list
>    - JDK-6964164 +MonitorInUseLists can cause leakage of contended objects
>      https://bugs.openjdk.java.net/browse/JDK-6964164
>    - integrated in jdk-7+102
>
>    - This integration added the global in-use list since having just a
>      global block-list and global free-list had some races that caused
>      leaks.
>    - I joined the Runtime team in Jan 2010, but I don't have exhaustive
>      records of this work.
>
> 2d) MonitorInUseLists on by default
>    - JDK-8149442 MonitorInUseLists should be on by default, deflate idle
> monitors taking too long
>      https://bugs.openjdk.java.net/browse/JDK-8149442
>    - integrated in jdk-9+120
>
>    - This default switch flip was done to improve the safepoint time
>      it takes to deflate idle monitors. The benchmarks done were again
>      safepoint focused.
>
> 3) async monitor deflation
>     - JDK-8153224 Monitor deflation prolong safepoints
>       https://bugs.openjdk.java.net/browse/JDK-8153224
>     - This evolution switched to async deflation and lock-free lists and
>       was very complicated.
>     -
> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>     - integrated in jdk-15+26
>
>     - Again the focus was on reducing safepoint time. Lots of benchmarking
>       done with the perf group. We got faster safepoints, but had to really
>       fight to avoid regressions in artifically contended benchmarks which
>       is where the lock-free lists stuff came from.
>
> 4) monitor list simplifications and getting rid of TSM
>     - JDK-8253064 monitor list simplifications and getting rid of TSM
>       https://bugs.openjdk.java.net/browse/JDK-8253064
>     - integrated in jdk-16+24
>
>     - Not much to add here about 8253064. We wanted to get rid of TSM to
>       make other work simpler. Getting rid of TSM allowed us to switch to
>       much simpler list management logic. So we got rid of a lot of the
>       logic that we added with async monitor deflation (8153224).
>     - Lots of benchmarking done with the perf group and those
> pre-integration
>       benchmarks showed no worrisome regressions and some speedups.
>     - Later benchmarking showed some regressions (that have since been
> fixed)
>       and we never figured out why we had different results later
> compared to
>       the pre-integration benchmarks. One theory is that we see different
>       results in AMD-X64 versus Intel-X64.
>
>
> >> You can always create a benchmark to show contention in the monitor
> >> inflation code. I don't recall now whether this was a real issue or a
> >> microbenchmark issue. As the code stated:
> >>
> >> ObjectMonitor * ATTR ObjectSynchronizer::omAlloc (Thread * Self) {
> >>       // A large MAXPRIVATE value reduces both list lock contention
> >>       // and list coherency traffic, but also tends to increase the
> >>       // number of objectMonitors in circulation as well as the STW
> >>       // scavenge costs.  As usual, we lean toward time in space-time
> >>       // tradeoffs.
> >>
> >>       const int MAXPRIVATE = 1024 ;
> >>
> >> so general performance was a consideration.
> >>
> >>> OTOH the new code just uses malloc, which also may lock depending on
> the
> >>> malloc allocator internals and the used libc settings. Therefore I
> >>> wonder whether OM allocation is still a problem, not a problem with
> >>> real-life malloc, or maybe never really had been a problem and the old
> >>> code was just overly cautious?
> >> Whenever we make significant changes to a subsystem we always
> >> investigate the performance profile of the changes. We're prepared to
> >> accept some performance loss if we have a good improvement in code
> >> complexity/maintainability etc, but if a significant performance issue
> >> arose we would revisit it. See for example discussion in:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8263864
> >>
> >> and related.
>
> We have not seen any performance regressions that we can attribute to
> malloc lock contention. In fact, I had to put upper limits on my personal
> ObjectMonitor inflation stress programs because they could allocate
> inflated ObjectMonitors so fast that the MonitorDeflationThread could
> not keep up. You'll notice that the deflation code now stops its
> current loop at 1 million objects and takes a check-for-a-safepoint
> breather. So I would say that malloc() of ObjectMonitor is not a
> performance issue any longer. I believe Dice said that it was before
> back in the JDK6 days, but no longer...
>
>
> Hopefully some of this history stuff is useful.
>
> Dan
>
>
>
> >>
> >> Cheers,
> >> David
> >> -----
> >>
> >>> Thanks, Thomas
> >>>
> >>>
>
>

From kbarrett at openjdk.java.net  Wed Feb  9 06:51:17 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Feb 2022 06:51:17 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v2]
In-Reply-To: <l70LYhh2oqauHCa5hTQli9U1dFHs6PDSO9pckLzkOsU=.c07d4432-2e64-4df4-bcbc-8ae41dfa3bed@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <l70LYhh2oqauHCa5hTQli9U1dFHs6PDSO9pckLzkOsU=.c07d4432-2e64-4df4-bcbc-8ae41dfa3bed@github.com>
Message-ID: <N1A-bbg4vlhhrN-fX8HfzxA-OxWWW_DYq8NjVZeeiJ4=.47a879a3-bab1-4c6e-bc68-046fa5bb6270@github.com>

On Fri, 4 Feb 2022 05:32:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> release_multi_mappings_vm is unfortunately racy.
>> 
>> The original intention of the test was to check that `os::release_memory()` works across multiple mappings allocated with multiple calls to `os::reserve_memory()`. This was broken for a long time on windows, since it relies on the implicit assumption that every platform uses mmap-ish APIs under the hood. But Windows virtual memory API (and SysV shmat, for that matter) does not work that way.
>> 
>> The release_multi_mappings_vm test 
>> - A reserves a number of mappings in 4M stripes adjacent to each other 
>> - B releases them with a single call to os::release_memory
>> - C re-allocates a range at the same address
>> 
>> Step (C) will fail if the os::release call in (B) failed to release the mapping. Which it sometimes did silently, so just checking the return code in (B) was not sufficient.
>> 
>> Unfortunately, it will also fail if someone concurrently mapped into the range between (B) and (C). It's rare, but it happens.
>> 
>> This is difficult to make completely airtight, but we could make it much more stable:
>> 1) instead of releasing all stripes, just release the n middle stripes (n>1) and leave first and last stripe reserved. Then, in (C), re-reserve the middle stripes. Tests the same (as long as we have multiple middle stripes) but drastically decreases the chance of some random allocation placing memory into the vacated address hole
>> 2) reduce the stripe size from today's 4M to something much smaller. Again, reduces the chance of stray mappings being placed into the hole since it will be smaller too.
>> 
>> The patch does just that.
>> It also adds a lengthy comment.
>> I also needed to place the NUMASwitcher line in front of the last os::release_memory. That is done just  to clean up everything before the tests ends, but now its a multi-mapping-release too (we now release front stripe, middle, and end stripe).
>> 
>> Tests:
>> - GHAs
>> - manually ran the test on x64 Linux
>> - SAP nightlies
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dans remarks

Changes requested by kbarrett (Reviewer).

test/hotspot/gtest/runtime/test_os.cpp line 449:

> 447:   if (MemTracker::tracking_level() > NMT_off) {
> 448:     return;
> 449:   }

Not a review (I'm not an expert in the relevant area), just a couple drive-by comments.  However, GitHub UI won't let me comment on the parts that I want.  So getting as close as I can.

(1) The `TEST_VM` line should be outdented.

(2) After 8277822, I think the tracking level is always going to be > `NMT_off` in a debug build, so we'll only be testing in product builds.  That seems problematic.

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From kbarrett at openjdk.java.net  Wed Feb  9 06:59:51 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Feb 2022 06:59:51 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch [v4]
In-Reply-To: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
Message-ID: <f333rQfFQISDAOnkawlY7F2DOLOZlTjYNJbfaW6C6k4=.6171a023-85cf-4cff-a261-b5d6eb191f18@github.com>

> [Trying again, after a couple previous proposals.]
> 
> Please review this change to os::pretouch_memory to permit use of the memory
> being pretouched concurrently with the pretouch operation.  This will allow
> future changes that can make use of such overlap.
> 
> Testing:
> mach5 tier1-3 with -XX:+AlwaysPreTouch.
> 
> Verified no performance impact by comparing startup times with Epsilon GC and
> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
> 
> None of these test concurrent use; that will wait for future changes that use
> the new feature.

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

 - Merge branch 'master' into conc-pretouch2
 - change loop termination test
 - assert range is valid
 - pretouch allowing concurrent access

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7343/files
  - new: https://git.openjdk.java.net/jdk/pull/7343/files/2e4e66a0..7fd0be0b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7343&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7343&range=02-03

  Stats: 5280 lines in 106 files changed: 4018 ins; 743 del; 519 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7343.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7343/head:pull/7343

PR: https://git.openjdk.java.net/jdk/pull/7343

From kbarrett at openjdk.java.net  Wed Feb  9 06:59:54 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Feb 2022 06:59:54 GMT
Subject: Integrated: 8272807: Permit use of memory concurrent with pretouch
In-Reply-To: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
Message-ID: <x7EvjsDPu9IHJP0xnK4wNQ95B_x-UWYq-eiuWDVgn08=.1eccaa36-894d-4cd2-8eac-95b36525856e@github.com>

On Fri, 4 Feb 2022 10:47:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> [Trying again, after a couple previous proposals.]
> 
> Please review this change to os::pretouch_memory to permit use of the memory
> being pretouched concurrently with the pretouch operation.  This will allow
> future changes that can make use of such overlap.
> 
> Testing:
> mach5 tier1-3 with -XX:+AlwaysPreTouch.
> 
> Verified no performance impact by comparing startup times with Epsilon GC and
> -XX:+AlwaysPretouch on a large enough heap that the pretouch takes a
> significant amount of time.  Tested on both linux-x64 and linux-aarch64.
> 
> None of these test concurrent use; that will wait for future changes that use
> the new feature.

This pull request has now been integrated.

Changeset: 072e7b4d
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/072e7b4da0449ab7c1ab1ba0cfbb3db233823e7c
Stats:     28 lines in 2 files changed: 18 ins; 1 del; 9 mod

8272807: Permit use of memory concurrent with pretouch

Reviewed-by: shade, stuefe

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From kbarrett at openjdk.java.net  Wed Feb  9 06:59:53 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Feb 2022 06:59:53 GMT
Subject: RFR: 8272807: Permit use of memory concurrent with pretouch [v3]
In-Reply-To: <Cly_UHmqsfoxLc8pavYpQgWh0jh0sm9hRftlGSM7BIU=.a595cd42-9657-4cd4-9709-d672673a2fc3@github.com>
References: <9aWixXJfMsQ-FvsaA4hzw8pK1P35M4pwgxaks-n1MlQ=.87054f05-8e18-41cc-845a-f201562bde54@github.com>
 <3o6IaUW6rUnp7gwu4aAYZoqwhUzv8MwxLfNSH6sIrZs=.b21ec7d0-0d20-44d8-9515-f952cfefb9e7@github.com>
 <Cly_UHmqsfoxLc8pavYpQgWh0jh0sm9hRftlGSM7BIU=.a595cd42-9657-4cd4-9709-d672673a2fc3@github.com>
Message-ID: <6TpbTD-ahwpJUu4nql_HDTAIzuckOza7xWtHCO5dTy0=.3b09c3ba-c433-4507-8f20-19e994e8f310@github.com>

On Tue, 8 Feb 2022 14:37:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change loop termination test
>
> looks still good.

Thanks @tstuefe and @shipilev for reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/7343

From stuefe at openjdk.java.net  Wed Feb  9 07:10:06 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Feb 2022 07:10:06 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v2]
In-Reply-To: <N1A-bbg4vlhhrN-fX8HfzxA-OxWWW_DYq8NjVZeeiJ4=.47a879a3-bab1-4c6e-bc68-046fa5bb6270@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <l70LYhh2oqauHCa5hTQli9U1dFHs6PDSO9pckLzkOsU=.c07d4432-2e64-4df4-bcbc-8ae41dfa3bed@github.com>
 <N1A-bbg4vlhhrN-fX8HfzxA-OxWWW_DYq8NjVZeeiJ4=.47a879a3-bab1-4c6e-bc68-046fa5bb6270@github.com>
Message-ID: <WrkNiM5x4vo04QxedUnyHFcUT7_1iK5l-CDlQCP40Po=.fc347822-c924-47d6-be10-2a264272d2f5@github.com>

On Wed, 9 Feb 2022 06:47:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dans remarks
>
> test/hotspot/gtest/runtime/test_os.cpp line 449:
> 
>> 447:   if (MemTracker::tracking_level() > NMT_off) {
>> 448:     return;
>> 449:   }
> 
> Not a review (I'm not an expert in the relevant area), just a couple drive-by comments.  However, GitHub UI won't let me comment on the parts that I want.  So getting as close as I can.
> 
> (1) The `TEST_VM` line should be outdented.
> 
> (2) After 8277822, I think the tracking level is always going to be > `NMT_off` in a debug build, so we'll only be testing in product builds.  That seems problematic.

Hi Kim,

thanks for taking a look!

> Not a review (I'm not an expert in the relevant area), just a couple drive-by comments. However, GitHub UI won't let me comment on the parts that I want. So getting as close as I can.
> 
> (1) The `TEST_VM` line should be outdented.

Sure.

> 
> (2) After 8277822, I think the tracking level is always going to be > `NMT_off` in a debug build, so we'll only be testing in product builds. That seems problematic.

We run the gtests in all NMT modes (off, summary, default), see:

https://github.com/openjdk/jdk/blob/072e7b4da0449ab7c1ab1ba0cfbb3db233823e7c/test/hotspot/jtreg/gtest/NMTGtests.java#L30-L36

so we run these tests in debug builds with NMT=off. The NMT gtests have been introduced with 8256844 and extended to cover the os* tests with 8277822.

That said, I should take a look at 8263464, see if this still is a problem.

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From stuefe at openjdk.java.net  Wed Feb  9 07:20:38 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Feb 2022 07:20:38 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v3]
In-Reply-To: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
Message-ID: <qY2rvEcJxZOm6SEVdz0bQW9OVhAz2J8VS7M12Nfada0=.ebe6f12f-6c93-4d83-8c92-6ff985792549@github.com>

> release_multi_mappings_vm is unfortunately racy.
> 
> The original intention of the test was to check that `os::release_memory()` works across multiple mappings allocated with multiple calls to `os::reserve_memory()`. This was broken for a long time on windows, since it relies on the implicit assumption that every platform uses mmap-ish APIs under the hood. But Windows virtual memory API (and SysV shmat, for that matter) does not work that way.
> 
> The release_multi_mappings_vm test 
> - A reserves a number of mappings in 4M stripes adjacent to each other 
> - B releases them with a single call to os::release_memory
> - C re-allocates a range at the same address
> 
> Step (C) will fail if the os::release call in (B) failed to release the mapping. Which it sometimes did silently, so just checking the return code in (B) was not sufficient.
> 
> Unfortunately, it will also fail if someone concurrently mapped into the range between (B) and (C). It's rare, but it happens.
> 
> This is difficult to make completely airtight, but we could make it much more stable:
> 1) instead of releasing all stripes, just release the n middle stripes (n>1) and leave first and last stripe reserved. Then, in (C), re-reserve the middle stripes. Tests the same (as long as we have multiple middle stripes) but drastically decreases the chance of some random allocation placing memory into the vacated address hole
> 2) reduce the stripe size from today's 4M to something much smaller. Again, reduces the chance of stray mappings being placed into the hole since it will be smaller too.
> 
> The patch does just that.
> It also adds a lengthy comment.
> I also needed to place the NUMASwitcher line in front of the last os::release_memory. That is done just  to clean up everything before the tests ends, but now its a multi-mapping-release too (we now release front stripe, middle, and end stripe).
> 
> Tests:
> - GHAs
> - manually ran the test on x64 Linux
> - SAP nightlies

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

  fix indentation of TEST_VM line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7288/files
  - new: https://git.openjdk.java.net/jdk/pull/7288/files/f6014cc5..0a0a9d7f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7288&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7288&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From stuefe at openjdk.java.net  Wed Feb  9 07:20:40 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Feb 2022 07:20:40 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v2]
In-Reply-To: <WrkNiM5x4vo04QxedUnyHFcUT7_1iK5l-CDlQCP40Po=.fc347822-c924-47d6-be10-2a264272d2f5@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <l70LYhh2oqauHCa5hTQli9U1dFHs6PDSO9pckLzkOsU=.c07d4432-2e64-4df4-bcbc-8ae41dfa3bed@github.com>
 <N1A-bbg4vlhhrN-fX8HfzxA-OxWWW_DYq8NjVZeeiJ4=.47a879a3-bab1-4c6e-bc68-046fa5bb6270@github.com>
 <WrkNiM5x4vo04QxedUnyHFcUT7_1iK5l-CDlQCP40Po=.fc347822-c924-47d6-be10-2a264272d2f5@github.com>
Message-ID: <AhBakjroHwCmvr97HX4fdwb6CbajywKI1c8h6XKfxEQ=.d1f5317d-aca4-4d55-a391-97b19a068cc5@github.com>

On Wed, 9 Feb 2022 07:06:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> test/hotspot/gtest/runtime/test_os.cpp line 449:
>> 
>>> 447:   if (MemTracker::tracking_level() > NMT_off) {
>>> 448:     return;
>>> 449:   }
>> 
>> Not a review (I'm not an expert in the relevant area), just a couple drive-by comments.  However, GitHub UI won't let me comment on the parts that I want.  So getting as close as I can.
>> 
>> (1) The `TEST_VM` line should be outdented.
>> 
>> (2) After 8277822, I think the tracking level is always going to be > `NMT_off` in a debug build, so we'll only be testing in product builds.  That seems problematic.
>
> Hi Kim,
> 
> thanks for taking a look!
> 
>> Not a review (I'm not an expert in the relevant area), just a couple drive-by comments. However, GitHub UI won't let me comment on the parts that I want. So getting as close as I can.
>> 
>> (1) The `TEST_VM` line should be outdented.
> 
> Sure.
> 
>> 
>> (2) After 8277822, I think the tracking level is always going to be > `NMT_off` in a debug build, so we'll only be testing in product builds. That seems problematic.
> 
> We run the gtests in all NMT modes (off, summary, default), see:
> 
> https://github.com/openjdk/jdk/blob/072e7b4da0449ab7c1ab1ba0cfbb3db233823e7c/test/hotspot/jtreg/gtest/NMTGtests.java#L30-L36
> 
> so we run these tests in debug builds with NMT=off. The NMT gtests have been introduced with 8256844 and extended to cover the os* tests with 8277822.
> 
> That said, I should take a look at 8263464, see if this still is a problem.
> 
> Cheers, Thomas

Okay, https://bugs.openjdk.java.net/browse/JDK-8263464 is still a problem. This means that even though we can release multiple mappings with os::release_memory, NMT cannot cope with that.

AFAIK the only real example of releasing multiple segments in one go is Windows + UseNUMA, and there os::release_memory(), when called over multiple segments, just recursively releases the segments individually. So I believe this works with NMT. Still, it would be nice to fix this.

@zhengyu123 : do you think https://bugs.openjdk.java.net/browse/JDK-8263464 is difficult to fix? Should I take a stab at it or do you want to take a look?

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From dholmes at openjdk.java.net  Wed Feb  9 07:29:11 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Feb 2022 07:29:11 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v5]
In-Reply-To: <KFc5tuJNSC7VtkGhJz6DN9jzcJnStWdNkHX7bEcAAHk=.bc10de29-3ed8-4bfa-9b53-4898d07897ac@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
 <KFc5tuJNSC7VtkGhJz6DN9jzcJnStWdNkHX7bEcAAHk=.bc10de29-3ed8-4bfa-9b53-4898d07897ac@github.com>
Message-ID: <D9zgVmQpuapqcBggCFKKqbAptR-1nBgCf8Bn58JzGoE=.777f96a5-46b9-43b6-9cd8-8b2a5d49b869@github.com>

On Wed, 9 Feb 2022 03:45:47 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Fixes
>> 
>> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
>> 
>> eliminating frequent generation of log messages with no respect of logging configuration
>> 
>> Verification: N/A (the issue does not have an observable effect)
>> 
>> Regression: hotspot_compiler (20.04 on amd64 )
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Replacing multiple if statements with single one"
>   
>   This reverts commit 34713cf2619c594527022a6ac29ee55df8e61f97.

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From duke at openjdk.java.net  Wed Feb  9 07:35:42 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Wed, 9 Feb 2022 07:35:42 GMT
Subject: RFR: 8281195: Mistakenly used logging causes significant overhead
 in interpreter [v6]
In-Reply-To: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
Message-ID: <OKhIFLC68tqVCTVQ5Gb7kijonkNLquphOFnUeh6Qtbw=.aae13f8a-92ea-4999-bd71-74a2131ae51f@github.com>

> Fixes
> 
> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
> 
> eliminating frequent generation of log messages with no respect of logging configuration
> 
> Verification: N/A (the issue does not have an observable effect)
> 
> Regression: hotspot_compiler (20.04 on amd64 )

Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:

  Updating copyrights

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7367/files
  - new: https://git.openjdk.java.net/jdk/pull/7367/files/684ee0dd..7ee16e71

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7367&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From mbaesken at openjdk.java.net  Wed Feb  9 08:14:39 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 9 Feb 2022 08:14:39 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v5]
In-Reply-To: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
Message-ID: <wGCr_lngreuGadW5csT42Z_jNleMN8FoujjL3K_ypPM=.5626101f-0330-42f8-aae6-69824d8593f1@github.com>

> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.

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

  Avoid changing Common.java, simplify test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7354/files
  - new: https://git.openjdk.java.net/jdk/pull/7354/files/29352421..9444430e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7354&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7354&range=03-04

  Stats: 14 lines in 2 files changed: 2 ins; 7 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7354/head:pull/7354

PR: https://git.openjdk.java.net/jdk/pull/7354

From mbaesken at openjdk.java.net  Wed Feb  9 08:14:41 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 9 Feb 2022 08:14:41 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v4]
In-Reply-To: <AmZTNV4hm7z0gDQl6V_GuiSz30io0u9KWaR9rpL3NHI=.8b4efe37-941b-440e-9e62-82f4ac08eb46@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <AmZTNV4hm7z0gDQl6V_GuiSz30io0u9KWaR9rpL3NHI=.8b4efe37-941b-440e-9e62-82f4ac08eb46@github.com>
Message-ID: <NX7prRWgCU6NPWBK2yL4ulat3Ul_LM8JRLcDYAZo9k4=.c96cbc65-32d4-48cd-94cc-b0de8472f541@github.com>

On Tue, 8 Feb 2022 15:21:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
>> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add separate testPrintContainerInfoActiveProcessorCount, avoid code duplication in Common

Hi Severin, indeed we can live without changing Common.java; adjusted the test.
Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From kbarrett at openjdk.java.net  Wed Feb  9 08:21:06 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Feb 2022 08:21:06 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v2]
In-Reply-To: <AhBakjroHwCmvr97HX4fdwb6CbajywKI1c8h6XKfxEQ=.d1f5317d-aca4-4d55-a391-97b19a068cc5@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <l70LYhh2oqauHCa5hTQli9U1dFHs6PDSO9pckLzkOsU=.c07d4432-2e64-4df4-bcbc-8ae41dfa3bed@github.com>
 <N1A-bbg4vlhhrN-fX8HfzxA-OxWWW_DYq8NjVZeeiJ4=.47a879a3-bab1-4c6e-bc68-046fa5bb6270@github.com>
 <WrkNiM5x4vo04QxedUnyHFcUT7_1iK5l-CDlQCP40Po=.fc347822-c924-47d6-be10-2a264272d2f5@github.com>
 <AhBakjroHwCmvr97HX4fdwb6CbajywKI1c8h6XKfxEQ=.d1f5317d-aca4-4d55-a391-97b19a068cc5@github.com>
Message-ID: <IumWsIgHo1t2_q7Ki9q8O6J1DktTav2Nx756qL8Tl3I=.e61d682e-8349-492a-800e-7f23a9f42409@github.com>

On Wed, 9 Feb 2022 07:14:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi Kim,
>> 
>> thanks for taking a look!
>> 
>>> Not a review (I'm not an expert in the relevant area), just a couple drive-by comments. However, GitHub UI won't let me comment on the parts that I want. So getting as close as I can.
>>> 
>>> (1) The `TEST_VM` line should be outdented.
>> 
>> Sure.
>> 
>>> 
>>> (2) After 8277822, I think the tracking level is always going to be > `NMT_off` in a debug build, so we'll only be testing in product builds. That seems problematic.
>> 
>> We run the gtests in all NMT modes (off, summary, default), see:
>> 
>> https://github.com/openjdk/jdk/blob/072e7b4da0449ab7c1ab1ba0cfbb3db233823e7c/test/hotspot/jtreg/gtest/NMTGtests.java#L30-L36
>> 
>> so we run these tests in debug builds with NMT=off. The NMT gtests have been introduced with 8256844 and extended to cover the os* tests with 8277822.
>> 
>> That said, I should take a look at 8263464, see if this still is a problem.
>> 
>> Cheers, Thomas
>
> Okay, https://bugs.openjdk.java.net/browse/JDK-8263464 is still a problem. This means that even though we can release multiple mappings with os::release_memory, NMT cannot cope with that.
> 
> AFAIK the only real example of releasing multiple segments in one go is Windows + UseNUMA, and there os::release_memory(), when called over multiple segments, just recursively releases the segments individually. So I believe this works with NMT. Still, it would be nice to fix this.
> 
> @zhengyu123 : do you think https://bugs.openjdk.java.net/browse/JDK-8263464 is difficult to fix? Should I take a stab at it or do you want to take a look?

There used to not be a way to run gtests with non-default -XX:whatever
arguments and the like. But it looks like you did something about that in
JDK-8251158. I had no idea!

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From stuefe at openjdk.java.net  Wed Feb  9 08:29:03 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Feb 2022 08:29:03 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v2]
In-Reply-To: <IumWsIgHo1t2_q7Ki9q8O6J1DktTav2Nx756qL8Tl3I=.e61d682e-8349-492a-800e-7f23a9f42409@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <l70LYhh2oqauHCa5hTQli9U1dFHs6PDSO9pckLzkOsU=.c07d4432-2e64-4df4-bcbc-8ae41dfa3bed@github.com>
 <N1A-bbg4vlhhrN-fX8HfzxA-OxWWW_DYq8NjVZeeiJ4=.47a879a3-bab1-4c6e-bc68-046fa5bb6270@github.com>
 <WrkNiM5x4vo04QxedUnyHFcUT7_1iK5l-CDlQCP40Po=.fc347822-c924-47d6-be10-2a264272d2f5@github.com>
 <AhBakjroHwCmvr97HX4fdwb6CbajywKI1c8h6XKfxEQ=.d1f5317d-aca4-4d55-a391-97b19a068cc5@github.com>
 <IumWsIgHo1t2_q7Ki9q8O6J1DktTav2Nx756qL8Tl3I=.e61d682e-8349-492a-800e-7f23a9f42409@github.com>
Message-ID: <6tL6uvCDLlZMG9twag5dz8qx-gdLWIiBxYidcbiH4zk=.92082976-31c8-42d5-9535-4827514d646b@github.com>

On Wed, 9 Feb 2022 08:17:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Okay, https://bugs.openjdk.java.net/browse/JDK-8263464 is still a problem. This means that even though we can release multiple mappings with os::release_memory, NMT cannot cope with that.
>> 
>> AFAIK the only real example of releasing multiple segments in one go is Windows + UseNUMA, and there os::release_memory(), when called over multiple segments, just recursively releases the segments individually. So I believe this works with NMT. Still, it would be nice to fix this.
>> 
>> @zhengyu123 : do you think https://bugs.openjdk.java.net/browse/JDK-8263464 is difficult to fix? Should I take a stab at it or do you want to take a look?
>
> There used to not be a way to run gtests with non-default -XX:whatever
> arguments and the like. But it looks like you did something about that in
> JDK-8251158. I had no idea!

:) thanks. Yes, I was afraid of missing out on tests. Since then, we have embraced this pattern of XX-specific gtests. It's a nice way to get test coverage with not much effort.

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From sgehwolf at openjdk.java.net  Wed Feb  9 09:09:05 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 9 Feb 2022 09:09:05 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v5]
In-Reply-To: <wGCr_lngreuGadW5csT42Z_jNleMN8FoujjL3K_ypPM=.5626101f-0330-42f8-aae6-69824d8593f1@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <wGCr_lngreuGadW5csT42Z_jNleMN8FoujjL3K_ypPM=.5626101f-0330-42f8-aae6-69824d8593f1@github.com>
Message-ID: <HTdX6F4Q0iAwez_eXqgZJRCTij8NlKuIpFt9Lzw__5Y=.dbffaf46-c2a8-400a-815f-a3bb7e69ae56@github.com>

On Wed, 9 Feb 2022 08:14:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
>> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid changing Common.java, simplify test

Marked as reviewed by sgehwolf (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From dholmes at openjdk.java.net  Wed Feb  9 09:10:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Feb 2022 09:10:06 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <2HDkOBHlI6OfbNyu5y5UflCD7bmBDtgEDiXCEJ-Izbk=.d57634ec-dcfc-4492-bb5b-23757d17504a@github.com>

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

Introducing a category just to collect info on a specific kind of allocation does seem somewhat fragile. I can easily imagine someone looking at ObjectMonitorHashtable and thinking it should be tagged too. But in the meantime if this serves a purpose ...

IIRC we have some existing stats we can report about ObjectMonitors if that helps.

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From duke at openjdk.java.net  Wed Feb  9 09:37:11 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Wed, 9 Feb 2022 09:37:11 GMT
Subject: Integrated: 8281195: Mistakenly used logging causes significant
 overhead in interpreter
In-Reply-To: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
References: <_6ATNKZVvywW1-5LeYD_htJ65a9KHH4rrHljBBn1pgE=.54384134-eb4e-4aae-82a1-fe78fe6100eb@github.com>
Message-ID: <m5zGXNv_Ron-Nl7A3SUxzkd3BomCc2p_9BqSWdCfHbE=.54dd426c-205b-4f04-aae6-6c3e9d9bbcf0@github.com>

On Mon, 7 Feb 2022 13:32:13 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Fixes
> 
> `bool OopMapCacheEntry::verify_mask(CellTypeState* vars, CellTypeState* stack, int max_locals, int stack_top)`
> 
> eliminating frequent generation of log messages with no respect of logging configuration
> 
> Verification: N/A (the issue does not have an observable effect)
> 
> Regression: hotspot_compiler (20.04 on amd64 )

This pull request has now been integrated.

Changeset: f092baba
Author:    Alexey Pavlyutkin <apavlyutkin at azul.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f092babafb58563a4044463e157e02c397d8c9bc
Stats:     9 lines in 1 file changed: 0 ins; 0 del; 9 mod

8281195: Mistakenly used logging causes significant overhead in interpreter

Reviewed-by: shade, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/7367

From stuefe at openjdk.java.net  Wed Feb  9 09:48:08 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Feb 2022 09:48:08 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <2HDkOBHlI6OfbNyu5y5UflCD7bmBDtgEDiXCEJ-Izbk=.d57634ec-dcfc-4492-bb5b-23757d17504a@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
 <2HDkOBHlI6OfbNyu5y5UflCD7bmBDtgEDiXCEJ-Izbk=.d57634ec-dcfc-4492-bb5b-23757d17504a@github.com>
Message-ID: <HbcIqnVwaq9DGgSYydWUYmstnrFoZDJCRNIfyFJzHNs=.4c401d73-3d99-49bf-88d3-2aa80f666204@github.com>

On Wed, 9 Feb 2022 09:07:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Introducing a category just to collect info on a specific kind of allocation does seem somewhat fragile. I can easily imagine someone looking at ObjectMonitorHashtable and thinking it should be tagged too. But in the meantime if this serves a purpose ...

It feels weird now :) but let us see if someone else objects. If yes, I withdraw this change.

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From shade at openjdk.java.net  Wed Feb  9 10:07:02 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 9 Feb 2022 10:07:02 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <HbcIqnVwaq9DGgSYydWUYmstnrFoZDJCRNIfyFJzHNs=.4c401d73-3d99-49bf-88d3-2aa80f666204@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
 <2HDkOBHlI6OfbNyu5y5UflCD7bmBDtgEDiXCEJ-Izbk=.d57634ec-dcfc-4492-bb5b-23757d17504a@github.com>
 <HbcIqnVwaq9DGgSYydWUYmstnrFoZDJCRNIfyFJzHNs=.4c401d73-3d99-49bf-88d3-2aa80f666204@github.com>
Message-ID: <bMerM0u9Vzgj9ECmRuz_O4c3Bm2X-_ChW-LVMPrhySk=.64e74ebe-4a56-4955-abb5-076cffe1d6c7@github.com>

On Wed, 9 Feb 2022 09:44:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It feels weird now :) but let us see if someone else objects. If yes, I withdraw this change.

Yeah, that looks a bit weird, and I have another question: why aren't both `ObjectMonitor` and `ObjectMonitorsHashtable` are `mtSynchronizer`?

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From stuefe at openjdk.java.net  Wed Feb  9 10:23:11 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Feb 2022 10:23:11 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <bMerM0u9Vzgj9ECmRuz_O4c3Bm2X-_ChW-LVMPrhySk=.64e74ebe-4a56-4955-abb5-076cffe1d6c7@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
 <2HDkOBHlI6OfbNyu5y5UflCD7bmBDtgEDiXCEJ-Izbk=.d57634ec-dcfc-4492-bb5b-23757d17504a@github.com>
 <HbcIqnVwaq9DGgSYydWUYmstnrFoZDJCRNIfyFJzHNs=.4c401d73-3d99-49bf-88d3-2aa80f666204@github.com>
 <bMerM0u9Vzgj9ECmRuz_O4c3Bm2X-_ChW-LVMPrhySk=.64e74ebe-4a56-4955-abb5-076cffe1d6c7@github.com>
Message-ID: <T4SVEFyzOGbSgbjQ4DnJK61o9Yo4JAB_HFEQidAq4rE=.6a23f6b1-3ef5-4ee1-a31d-4035a7ba1ce2@github.com>

On Wed, 9 Feb 2022 10:03:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > It feels weird now :) but let us see if someone else objects. If yes, I withdraw this change.
> 
> Yeah, that looks a bit weird, and I have another question: why aren't both `ObjectMonitor` and `ObjectMonitorsHashtable` are `mtSynchronizer`?

No idea. My guess is that ObjectMonitor is mtInternal because of an oversight in JDK-8253064 and the hashtable is only used as an aid during thread dumps, so mtThread? Would be a question to @dcubed-ojdk.

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From mbaesken at openjdk.java.net  Wed Feb  9 11:38:15 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 9 Feb 2022 11:38:15 GMT
Subject: Integrated: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info
In-Reply-To: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
Message-ID: <qaRoD0iSWRypEi4KEDtQmTtz6KIMPC9jpQPUfUL458c=.3c35939e-7dda-46cd-a705-3bf39a6072a0@github.com>

On Fri, 4 Feb 2022 16:18:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.

This pull request has now been integrated.

Changeset: bb2e10cc
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bb2e10ccea0c0b89b06ace034c99253e9999ec47
Stats:     16 lines in 2 files changed: 14 ins; 0 del; 2 mod

8281274: deal with ActiveProcessorCount in os::Linux::print_container_info

Reviewed-by: stuefe, sgehwolf, dholmes, iklam

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From dholmes at openjdk.java.net  Wed Feb  9 12:20:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Feb 2022 12:20:06 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <KZR1BIuO0fV4AfeZxs9VLlbHaAnmQkn7rFOhdIbQy_Y=.ad62c0a2-491f-4639-83c5-a41cede8b0c2@github.com>

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

I think mtSynchronizer was for VM synchronization objects: mutexes, semaphore etc. Not ObjectMonitors. But as always if these conventions are not clearly known then "misuse" can creep in.

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From dholmes at openjdk.java.net  Wed Feb  9 12:24:07 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Feb 2022 12:24:07 GMT
Subject: RFR: JDK-8281274: deal with ActiveProcessorCount in
 os::Linux::print_container_info [v5]
In-Reply-To: <wGCr_lngreuGadW5csT42Z_jNleMN8FoujjL3K_ypPM=.5626101f-0330-42f8-aae6-69824d8593f1@github.com>
References: <VnQIPjODHIp0i6pzRBJY-M8xOVMVS2goQHtFioGMT2c=.1129f7de-0465-451f-a4f3-f07b4cf93827@github.com>
 <wGCr_lngreuGadW5csT42Z_jNleMN8FoujjL3K_ypPM=.5626101f-0330-42f8-aae6-69824d8593f1@github.com>
Message-ID: <Z1vToKE9SeH_f17ngVxeMzES4zWGNStc9QO8Yn3QnHU=.827114c3-f415-4bbd-ac68-87d967d7a9b0@github.com>

On Wed, 9 Feb 2022 08:14:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function os::Linux::print_container_info outputs memory- and cpu-related container information (when running in a containerized environment).
>> However in the case of active processor count , it currently just outputs the info from OSContainer::active_processor_count without  looking at  ActiveProcessorCount that can be set to overwrite the OSContainer::active_processor_count() - information. This should be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid changing Common.java, simplify test

Only a single reviewer approved the final version of these changes so it may have been prudent to seek a least one additional re-review. I had it on my to-do list. :)

The updated test looks much cleaner and simpler.

Thanks,
David

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

PR: https://git.openjdk.java.net/jdk/pull/7354

From vlivanov at openjdk.java.net  Wed Feb  9 14:00:23 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 9 Feb 2022 14:00:23 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported [v2]
In-Reply-To: <zkLhmbUpSp4oh5DjiboABU1c8tyLSL1WsDuHD7m_MlQ=.526f94a8-ae4e-4157-b2e2-26c53d9037ed@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
 <zkLhmbUpSp4oh5DjiboABU1c8tyLSL1WsDuHD7m_MlQ=.526f94a8-ae4e-4157-b2e2-26c53d9037ed@github.com>
Message-ID: <kaQK9AUUEzaqyhTOp5fxzs_Hv4mcxwBp0z3ja67bTPc=.f5f34998-138c-4956-b871-d4d0b3043121@github.com>

On Tue, 8 Feb 2022 14:55:53 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
>> 
>> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
>> 
>> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
>> 
>> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
>> 
>> Testing: hs-tier1 - hs-tier6
>
> Vladimir Ivanov 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:
> 
>  - fatal -> assert
>  - Merge branch 'master' into 8279822.cpe_in_error
>  - Compiler support of CP entries in error state

Thanks for the reviews, Vladimir and Tobias.

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

PR: https://git.openjdk.java.net/jdk/pull/7314

From vlivanov at openjdk.java.net  Wed Feb  9 14:00:24 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 9 Feb 2022 14:00:24 GMT
Subject: Integrated: 8279822: CI: Constant pool entries in error state are not
 supported
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <dcQRg0EkNxNQNqhQm2Vi_Mw_JLTS5EAuuIOLq93sVK4=.322b2bda-3861-45be-a3a1-2edbdf3dfba5@github.com>

On Tue, 1 Feb 2022 19:09:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
> 
> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
> 
> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
> 
> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
> 
> Testing: hs-tier1 - hs-tier6

This pull request has now been integrated.

Changeset: c5c8c064
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c5c8c0644d9442846de15422285fffeb91c3e0a1
Stats:     451 lines in 10 files changed: 361 ins; 48 del; 42 mod

8279822: CI: Constant pool entries in error state are not supported

Reviewed-by: kvn, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/7314

From dcubed at openjdk.java.net  Wed Feb  9 17:33:12 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 9 Feb 2022 17:33:12 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <1Iz2bZ0oYQj04TRLEKp1FoN4J0LHp6_xxGgiqrarhfU=.ac217516-5cd1-4e14-8af4-f245526f4bcd@github.com>

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

Actually `ObjectMonitor` is `mtInternal` in JDK-8253064 intentionally. Here's the original
code that allocated blocks of ObjectMonitors:


    void* real_malloc_addr = NEW_C_HEAP_ARRAY(char, aligned_size, mtInternal);
    temp = (PaddedObjectMonitor*)align_up(real_malloc_addr, OM_CACHE_LINE_SIZE);
    (void)memset((void *) temp, 0, neededsize);


so the change in allocation implementation in JDK-8253064 is consistent (NMT tag wise)
with what was there before.

That said, I have no complaints about using a specific NMT tag. However, I would
have used "ObjectMonitors" instead of "Monitors" to avoid confusion with VM internal
Monitors. One good reason for this change is that NMT is used for analyzing unexpected
memory usages and since we changed the allocation implementation and some of the
policy in JDK-8253064 it would be good to "highlight" that in NMT as we continue to
shake out what we did in JDK-8253064.

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From dcubed at openjdk.java.net  Wed Feb  9 17:36:16 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 9 Feb 2022 17:36:16 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <QWgquU7DvPYz7sAkAQyduthWrKDbmgVg3HuNXNJwTWw=.d0d66c58-e1e8-41be-8f52-9c740d0bd388@github.com>

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

Thumbs up. I have one minor string rename request that
you can choose to ignore.

src/hotspot/share/memory/allocation.hpp line 149:

> 147:   f(mtMetaspace,      "Metaspace")                                                   \
> 148:   f(mtStringDedup,    "String Deduplication")                                        \
> 149:   f(mtObjectMonitor,  "Monitors")                                                    \

I would use "ObjectMonitors" in the string to distinguish from VM internal Monitors.
It also matches the `mtObjectMonitor` name better.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7378

From stuefe at openjdk.java.net  Wed Feb  9 17:42:16 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Feb 2022 17:42:16 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <QWgquU7DvPYz7sAkAQyduthWrKDbmgVg3HuNXNJwTWw=.d0d66c58-e1e8-41be-8f52-9c740d0bd388@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
 <QWgquU7DvPYz7sAkAQyduthWrKDbmgVg3HuNXNJwTWw=.d0d66c58-e1e8-41be-8f52-9c740d0bd388@github.com>
Message-ID: <HhfPUTZT8Tm9RzddtS6GYELmU_m-xZojPXYn_kNhV5c=.eb9c4611-ec58-4b37-a485-7ff79e6eb089@github.com>

On Wed, 9 Feb 2022 17:33:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Thumbs up. I have one minor string rename request that you can choose to ignore.

Thanks Dan! Your proposal makes sense, I'll change the string before pushing.

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From daniel.daugherty at oracle.com  Wed Feb  9 18:03:56 2022
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Wed, 9 Feb 2022 13:03:56 -0500
Subject: Small question about JDK-8253064 and ObjectMonitor allocation
In-Reply-To: <CAA-vtUzJ2CgXm4a2BBeOWUWXcDhoNdvfe9pOOmR4CNoFTkh0cA@mail.gmail.com>
References: <CAA-vtUx=3=cWGO-EXdVo23Os+c+CeBbbcuL+iA=7_b_W3TH0QQ@mail.gmail.com>
 <236484d3-0638-30d8-72dd-4dd3ce6e134a@oracle.com>
 <CAA-vtUwEgm4te2H4W=EoOry6ww5rZnn6Ty_hfAs1zg-AFc1AYQ@mail.gmail.com>
 <ad836150-899b-459e-8b30-1ddb0c173064@oracle.com>
 <CAA-vtUwOAPo1OFj=T-KhFDSe5VAdR+NjT0PFeuvLVx6dg72MQw@mail.gmail.com>
 <c46874ee-2d6e-81ec-ea86-c88461e89d76@oracle.com>
 <CAA-vtUzJ2CgXm4a2BBeOWUWXcDhoNdvfe9pOOmR4CNoFTkh0cA@mail.gmail.com>
Message-ID: <793211fc-ffb7-7126-2d34-976dc1cedea9@oracle.com>

On 2/9/22 1:34 AM, Thomas St?fe wrote:
> Hi,
>
> I wonder if I understand this correctly:
>
> - Monitors are only deflated by the MonitorDeflationThread, if I 
> ignore races on inflation

ObjectSynchronizer::deflate_idle_monitors() is called by:

- the MonitorDeflationThread in its work loop
- the VMThread at VM exit time via 
ObjectSynchronizer::do_final_audit_and_print_stats()
- the VMThread via VM_ThreadDump::doit() when locked_monitors are 
requested in the dump


> - The MonitorDeflationThread processes them in intervals of 250ms 
> (AsyncDeflationInterval),

The MonitorDeflationThread wakes up every 250ms to check to see if there
is work to do unless a deflation is requested in which case it wakes up
after the notify.


> but only if there are more than 90 (MonitorUsedDeflationThreshold) 
> monitors in use,

Not a count of 90; it is a percentage. Here's the option description:

 ? product(intx, MonitorUsedDeflationThreshold, 90, 
DIAGNOSTIC,????????????? \
 ????????? "Percentage of used monitors before triggering deflation (0 
is "? \
 ????????? "off). The check is performed on GuaranteedSafepointInterval 
"??? \
 ????????? "or 
AsyncDeflationInterval.")???????????????????????????????????? \
 ????????? range(0, 
100)???????????????????????????????????????????????????? \

So if the used monitors count is > 90% of the "ceiling", we trigger a
deflation. The initial ceiling estimate is based on a per-thread estimate,
but if the in-use list has had a maximum value greater than that estimate,
then we use the list maximum value.

See src/hotspot/share/runtime/synchronizer.cpp: 
monitors_used_above_threshold().


> and only in bulks of 1mio (MonitorDeflationMax).

Not quite in bulks of 1 million. Here's the option description:

 ? product(intx, MonitorDeflationMax, 1000000, 
DIAGNOSTIC,?????????????????? \
 ????????? "The maximum number of monitors to deflate, unlink and delete 
"?? \
 ????????? "at one time (minimum is 1024).")????????????????????? \
 ????????? range(1024, max_jint)

so we'll deflate up to MonitorDeflationMax at one time. If there's only 1
to deflate, then we'll do 1.


>
> Is there any upward bound preventing the creation of ObjectMonitors, 
> since creation races with this one thread,?and we also cap its ability 
> to process more than 1mio?

No, there is no upward bound. When the safepoint cleanup used to deflate 
idle
monitors, that was a "natural" limit on the creation rate by virtue of the
safepoint pausing the JavaThreads that were creating inflated ObjectMonitors
while the VMThread deflated all the monitors created during the previous
interval.


> The background of my question is that I try to get a feel for the 
> maximum number of live monitors.

There is no maximum number. If you have a badly behaving program that 
simply creates
inflated ObjectMonitors as fast as it can, then you'll eventually bring 
the VM to its
knees. As I've mentioned before, I've had to change the way that my 
ObjectMonitor
stress programs work because they would create more inflated 
ObjectMonitors that
could be dealt with by the MonitorDeflationThread.


> When running renaissance philosophers benchmark I see that the VM has, 
> depending on machine speed and optimization level, > 2.5 million live 
> ObjectMonitors, taking > 400MB heap space. Is this by design?

Sounds like a perfect use for a lower MonitorUsedDeflationThreshold 
value and
possibly a smaller AsyncDeflationInterval value, but I suspect that lowering
MonitorUsedDeflationThreshold would be "enough". Of course, that's just a
blind guess on my part.

Is this behavior by the renaissance philosophers benchmark considered a 
bug or
a feature?

>
> The annoying thing is that these peaks in C-heap usage can be sticky, 
> depending on libc implementation. The glibc especially has poor 
> reclaim behavior. Also, it is?hidden in NMT under "mtInternal", which 
> is why I propose to at least give it its own category 
> (https://bugs.openjdk.java.net/browse/JDK-8281450).

I think you mean:

 ??? JDK-8281460 Let ObjectMonitor have its own NMT category
https://bugs.openjdk.java.net/browse/JDK-8281460

instead of:

 ??? JDK-8281450 Remove unnecessary operator new and delete from 
ObjectMonitor
https://bugs.openjdk.java.net/browse/JDK-8281450

Dan



>
> Thanks, Thomas
>
> On Mon, Jan 31, 2022 at 11:59 PM <daniel.daugherty at oracle.com> wrote:
>
>     Greetings,
>
>     I'm going to try and add some historical context here...
>
>
>     On 1/31/22 3:09 AM, Thomas St?fe wrote:
>     > Thanks a lot for your answers, David.
>
>     Yes David, thanks for jumping in on this thread.
>
>
>     > On Mon, Jan 31, 2022 at 8:35 AM David Holmes
>     <david.holmes at oracle.com>
>     > wrote:
>     >
>     >> On 31/01/2022 3:54 pm, Thomas St?fe wrote:
>     >>> Hi David,
>     >>>
>     >>> Thank you for the answer!
>     >>>
>     >>> On Mon, Jan 31, 2022 at 6:23 AM David Holmes
>     <david.holmes at oracle.com
>     >>> <mailto:david.holmes at oracle.com>> wrote:
>     >>>
>     >>>? ? ? Hi Thomas,
>     >>>
>     >>>? ? ? On 31/01/2022 2:32 pm, Thomas St?fe wrote:
>     >>>? ? ? ?> Hi,
>     >>>? ? ? ?>
>     >>>? ? ? ?> I have a small question about a detail of JDK-8253064.
>     >>>? ? ? ?>
>     >>>? ? ? ?> IIUC, before this patch, the VM kept thread-local
>     freelists of
>     >>>? ? ? ?> pre-allocated ObjectMonitors to reduce allocation
>     contention. Now we just
>     >>>? ? ? ?> malloc monitors right away.
>     >>>? ? ? ?>
>     >>>? ? ? ?> I looked through the issue and the associated PR, but
>     could find no
>     >>>? ? ? ?> information on why this was done. Dan describes what
>     he did very well:
>     >>>? ? ? ?>
>     https://github.com/openjdk/jdk/pull/642#issuecomment-720753946,
>     but not
>     >>>? ? ? ?> why.
>
>     Thank you and I'm sorry that my words on 8253064 did not explain
>     the why.
>
>
>     >>>? ? ? ?> I assume that the complexity and memory overhead of
>     the free lists was not
>     >>>? ? ? ?> worth it? That you found that malloc() is on our
>     platforms "uncontented"
>     >>>? ? ? ?> enough?
>     >>>
>     >>>? ? ? The issue was not about freelists and contention it was
>     about requiring
>     >>>? ? ? type-stable-memory: that once a piece of memory was
>     allocated as an
>     >>>? ? ? ObjectMonitor it remained forever after an ObjectMonitor.
>     This allowed
>     >>>? ? ? for various race conditions in the old monitor code
>     maintaining safety.
>
>     Erik Osterlund did have some specific reasons for getting rid of
>     type-stable-memory.
>     At least on reason was that it was complicating the work he wanted
>     to do on:
>
>     ???? JDK-8247281 migrate ObjectMonitor::_object to OopStorage
>     https://bugs.openjdk.java.net/browse/JDK-8247281
>
>     He and I did work together to split this work into the various
>     pieces that
>     were integrated separately. So TSM didn't prevent work on
>     JDK-8247281, but
>     it did make it more difficult.
>
>     Erik may have had other reasons for getting rid of TSM. I've added
>     him to
>     this email thread directly so he has a better chance of seeing
>     this query.
>
>
>
>     >>>? ? ? Over time that code changed substantially and the need for
>     >>>? ? ? type-stable-memory for ObjectMonitors disappeared, so we
>     finally got rid
>     >>>? ? ? of it and just moved to a direct allocation scheme.
>     >>>
>     >>>
>     >>> I think I understand, but I was specifically concerned with
>     the question
>     >>> of allocation contention of ObjectMonitors. That is somewhat
>     independent
>     >>> from the question of where OMs are allocated.
>     >>>
>     >>> Can it happen that lock inflation happens clustered, or does
>     that not
>     >>> occur in reality?
>     >>>
>     >>> AFAIU the old code managed OM storage itself, used global data
>     >>> structures to do so, and guarded access with a mutex. To reduce
>     >>> contention, it used a surprisingly large thread-local freelist
>     of 1024
>     >>> entries. This looks like contention was once a real problem.
>
>     We need to take a step back and look at how we got where we are. There
>     are (at least) four different evolutions or seismic events to this
>     subsystem:
>
>     1) type-stable-memory and the global lists (block and free)
>     ?? - JDK-5030359 "Back-end" synchronization improvements for 1.5.1
>     or 1.6
>     https://bugs.openjdk.java.net/browse/JDK-5030359
>     ?? - integrated in jdk-6+50 (partial), jdk-6+53 (finished)
>
>     ?? - This integration introduced type-stable-memory (TSM) and
>     global block
>     ???? and free-lists. Dice chose to not use malloc and use TSM for
>     a few
>     ???? reasons:
>     ???? - direct control of the placement of the ObjectMonitor on a
>     cache-line
>     ?????? boundary; couldn't trust malloc to keep memory properly
>     aligned.
>     ???? - malloc was slower than direct management of blocks of
>     ObjectMonitors.
>     ???? - Dice did lots of benchmarking to prove the new code was
>     faster in
>     ?????? things we cared about at the time on the platforms we cared
>     about.
>     ?? - This predates my joining the Runtime team so I don't have
>     exhaustive
>     ???? records on this work.
>
>     2a) per-thread free list
>     ?? - JDK-6468954 Generic synchronization cleanups for J2SE 1.7
>     https://bugs.openjdk.java.net/browse/JDK-6468954
>     ?? - integrated in jdk-7+12
>
>     ?? - This integration introduced the per-thread free list. This
>     addition
>     ???? was to deal with contention with allocating an ObjectMonitor from
>     ???? the global free-list.
>     ?? - Again, Dice did targeted benchmarking to show that adding a
>     per-thread
>     ???? free list? performed better for some specific platforms/configs.
>     ?? - This predates my joining the Runtime team so I don't have
>     exhaustive
>     ???? records on this work.
>
>     2b) per-thread in-use list
>     ?? - JDK-6852873 Increase in delta between application stopped
>     time and
>     ParNew GC time over application lifetime
>     https://bugs.openjdk.java.net/browse/JDK-6852873
>     ?? - integrated in jdk-7+99
>
>     ?? - This integration added the MonitorInUseLists concept and was done
>     ???? as part of some work to deal with a safepoint performance
>     problem.
>     ?? - MonitorInUseLists was disabled by default.
>     ?? - The benchmarking done here was focused on safepointing.
>     ?? - I joined the Runtime team in Jan 2010, but I don't have
>     exhaustive
>     ???? records on this work.
>
>     2c) global in-use list
>     ?? - JDK-6964164 +MonitorInUseLists can cause leakage of contended
>     objects
>     https://bugs.openjdk.java.net/browse/JDK-6964164
>     ?? - integrated in jdk-7+102
>
>     ?? - This integration added the global in-use list since having just a
>     ???? global block-list and global free-list had some races that caused
>     ???? leaks.
>     ?? - I joined the Runtime team in Jan 2010, but I don't have
>     exhaustive
>     ???? records of this work.
>
>     2d) MonitorInUseLists on by default
>     ?? - JDK-8149442 MonitorInUseLists should be on by default,
>     deflate idle
>     monitors taking too long
>     https://bugs.openjdk.java.net/browse/JDK-8149442
>     ?? - integrated in jdk-9+120
>
>     ?? - This default switch flip was done to improve the safepoint time
>     ???? it takes to deflate idle monitors. The benchmarks done were again
>     ???? safepoint focused.
>
>     3) async monitor deflation
>     ??? - JDK-8153224 Monitor deflation prolong safepoints
>     https://bugs.openjdk.java.net/browse/JDK-8153224
>     ??? - This evolution switched to async deflation and lock-free
>     lists and
>     ????? was very complicated.
>     ??? -
>     https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>     ??? - integrated in jdk-15+26
>
>     ??? - Again the focus was on reducing safepoint time. Lots of
>     benchmarking
>     ????? done with the perf group. We got faster safepoints, but had
>     to really
>     ????? fight to avoid regressions in artifically contended
>     benchmarks which
>     ????? is where the lock-free lists stuff came from.
>
>     4) monitor list simplifications and getting rid of TSM
>     ??? - JDK-8253064 monitor list simplifications and getting rid of TSM
>     https://bugs.openjdk.java.net/browse/JDK-8253064
>     ??? - integrated in jdk-16+24
>
>     ??? - Not much to add here about 8253064. We wanted to get rid of
>     TSM to
>     ????? make other work simpler. Getting rid of TSM allowed us to
>     switch to
>     ????? much simpler list management logic. So we got rid of a lot
>     of the
>     ????? logic that we added with async monitor deflation (8153224).
>     ??? - Lots of benchmarking done with the perf group and those
>     pre-integration
>     ????? benchmarks showed no worrisome regressions and some speedups.
>     ??? - Later benchmarking showed some regressions (that have since
>     been
>     fixed)
>     ????? and we never figured out why we had different results later
>     compared to
>     ????? the pre-integration benchmarks. One theory is that we see
>     different
>     ????? results in AMD-X64 versus Intel-X64.
>
>
>     >> You can always create a benchmark to show contention in the monitor
>     >> inflation code. I don't recall now whether this was a real
>     issue or a
>     >> microbenchmark issue. As the code stated:
>     >>
>     >> ObjectMonitor * ATTR ObjectSynchronizer::omAlloc (Thread * Self) {
>     >>? ? ? ?// A large MAXPRIVATE value reduces both list lock contention
>     >>? ? ? ?// and list coherency traffic, but also tends to increase the
>     >>? ? ? ?// number of objectMonitors in circulation as well as the STW
>     >>? ? ? ?// scavenge costs.? As usual, we lean toward time in
>     space-time
>     >>? ? ? ?// tradeoffs.
>     >>
>     >>? ? ? ?const int MAXPRIVATE = 1024 ;
>     >>
>     >> so general performance was a consideration.
>     >>
>     >>> OTOH the new code just uses malloc, which also may lock
>     depending on the
>     >>> malloc allocator internals and the used libc settings. Therefore I
>     >>> wonder whether OM allocation is still a problem, not a problem
>     with
>     >>> real-life malloc, or maybe never really had been a problem and
>     the old
>     >>> code was just overly cautious?
>     >> Whenever we make significant changes to a subsystem we always
>     >> investigate the performance profile of the changes. We're
>     prepared to
>     >> accept some performance loss if we have a good improvement in code
>     >> complexity/maintainability etc, but if a significant
>     performance issue
>     >> arose we would revisit it. See for example discussion in:
>     >>
>     >> https://bugs.openjdk.java.net/browse/JDK-8263864
>     >>
>     >> and related.
>
>     We have not seen any performance regressions that we can attribute to
>     malloc lock contention. In fact, I had to put upper limits on my
>     personal
>     ObjectMonitor inflation stress programs because they could allocate
>     inflated ObjectMonitors so fast that the MonitorDeflationThread could
>     not keep up. You'll notice that the deflation code now stops its
>     current loop at 1 million objects and takes a check-for-a-safepoint
>     breather. So I would say that malloc() of ObjectMonitor is not a
>     performance issue any longer. I believe Dice said that it was before
>     back in the JDK6 days, but no longer...
>
>
>     Hopefully some of this history stuff is useful.
>
>     Dan
>
>
>
>     >>
>     >> Cheers,
>     >> David
>     >> -----
>     >>
>     >>> Thanks, Thomas
>     >>>
>     >>>
>

From cjplummer at openjdk.java.net  Wed Feb  9 19:49:05 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 9 Feb 2022 19:49:05 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times
In-Reply-To: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
Message-ID: <lktIplQUakJqH8pU7XBd6iZpJ8JxJAuQjShx0wo-iTA=.5a401ab7-603d-4668-9aaa-e1790f34420b@github.com>

On Tue, 8 Feb 2022 16:49:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> ClassLoaderDataGraph::classes_do description says:
> // Walking classes through the ClassLoaderDataGraph include array classes.
> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)

test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 58:

> 56:         String[][][] strArray = new String[0][][];
> 57:         LingeredApp.main(args);
> 58:         System.out.println("" + intArray + strArray);   // to be sure the classes are not unloaded

Use  Reference.reachabilityFence(<array>);

test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 86:

> 84:             Process p = ProcessTools.startProcess("jcmd", new ProcessBuilder(launcher.getCommand()));
> 85:             // If something goes wrong with heap dumping most likely we'll get crash of the target VM.
> 86:             while (!p.waitFor(5, TimeUnit.SECONDS)) {

5 seconds seems kind of short. Doesn't allow for occasional network hiccups.

test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 218:

> 216:     }
> 217: 
> 218:     // Reads the whole HPROF_GC_CLASS_DUMP record, returns closs ID.

"class ID"

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From cjplummer at openjdk.java.net  Wed Feb  9 20:20:10 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 9 Feb 2022 20:20:10 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times
In-Reply-To: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
Message-ID: <OWv3zarvAM6dR6eEiX9DNAYWvhndoNShmeJb39V6ViE=.7377d5c4-49fa-493d-9647-8ec58617ed94@github.com>

On Tue, 8 Feb 2022 16:49:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> ClassLoaderDataGraph::classes_do description says:
> // Walking classes through the ClassLoaderDataGraph include array classes.
> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)

src/hotspot/share/services/heapDumper.cpp line 2293:

> 2291:     // Writes HPROF_GC_CLASS_DUMP records
> 2292:     // For array classes we need signers and protection domain from their bottom classes
> 2293:     // so do_class_dump skips array classes and dumps array classes with corresponding instance class.

I'm having trouble parsing this comment. Can you clarify?

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From ccheung at openjdk.java.net  Wed Feb  9 23:09:25 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 9 Feb 2022 23:09:25 GMT
Subject: RFR: 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails
Message-ID: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>

A simple fix to the test failure by specifying the heap sizes for most of the test cases.
Before the fix, if the MaxHeapSize is determined by the VM, the MaxHeapSize could become smaller
than the MinHeapSize or the InitialHeapSize which causing the failure.

Testing: CI tiers 1 - 4.

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

Commit messages:
 - 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails

Changes: https://git.openjdk.java.net/jdk/pull/7413/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7413&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281186
  Stats: 23 lines in 1 file changed: 14 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7413.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7413/head:pull/7413

PR: https://git.openjdk.java.net/jdk/pull/7413

From minqi at openjdk.java.net  Thu Feb 10 00:04:04 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 10 Feb 2022 00:04:04 GMT
Subject: RFR: 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails
In-Reply-To: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
References: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
Message-ID: <INr-EMWyFEH5Jx1OD5hBca-mRlNO6IErP82DVXDM5t0=.def0f36a-ab0c-4709-9e2c-896208a54ccf@github.com>

On Wed, 9 Feb 2022 23:02:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A simple fix to the test failure by specifying the heap sizes for most of the test cases.
> Before the fix, if the MaxHeapSize is determined by the VM, the MaxHeapSize could become smaller
> than the MinHeapSize or the InitialHeapSize which causing the failure.
> 
> Testing: CI tiers 1 - 4.

LGTM

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7413

From dholmes at openjdk.java.net  Thu Feb 10 04:59:19 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Feb 2022 04:59:19 GMT
Subject: RFR: 8281275: Upgrading from 8 to 11 no longer accepts '/' as filepath
 separator in gc paths
Message-ID: <Hwe68MFCAH5D5rjbgZX_WqmIRPms0gyGknsd6DUGWvI=.fa3833cf-801b-45e2-b5f4-d1b4a9d396b0@github.com>

Please review this trivial fix for UL parsing logic on Windows. We already special-cased paths like c:\logfile but didn't allow for c:/logfile. As noted in the bug report this is a regression from using -Xloggc where the c:/ path was allowed (and it even worked when Xloggc was converted internally to use UL - because it skipped the parsing logic and just directly set the file output!).

Testing:
  - new gtest added by expanding existing parsing gtest
  - tiers 1-3 Windows

Verified that new gtest fails without the fix.

Thanks,
David

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

Commit messages:
 - Fix style issue
 - 8281275: Upgrading from 8 to 11 no longer accepts '/' as filepath separator in gc paths

Changes: https://git.openjdk.java.net/jdk/pull/7415/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7415&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281275
  Stats: 28 lines in 2 files changed: 23 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7415.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7415/head:pull/7415

PR: https://git.openjdk.java.net/jdk/pull/7415

From stuefe at openjdk.java.net  Thu Feb 10 05:32:04 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 10 Feb 2022 05:32:04 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <KZR1BIuO0fV4AfeZxs9VLlbHaAnmQkn7rFOhdIbQy_Y=.ad62c0a2-491f-4639-83c5-a41cede8b0c2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
 <KZR1BIuO0fV4AfeZxs9VLlbHaAnmQkn7rFOhdIbQy_Y=.ad62c0a2-491f-4639-83c5-a41cede8b0c2@github.com>
Message-ID: <PNb41ldK1xgMR8bVno15CZhDdrsK1lOF5C3BZdW3FGM=.305f492a-0d0c-4e6a-8e10-b3f1bcb10a15@github.com>

On Wed, 9 Feb 2022 12:16:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
>> 
>> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.
>
> I think mtSynchronizer was for VM synchronization objects: mutexes, semaphore etc. Not ObjectMonitors. But as always if these conventions are not clearly known then "misuse" can creep in.

@dholmes-ora @shipilev Dan confirmed my original idea makes sense, are you okay with this change too?

..Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From iklam at openjdk.java.net  Thu Feb 10 05:55:10 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 10 Feb 2022 05:55:10 GMT
Subject: RFR: 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails
In-Reply-To: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
References: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
Message-ID: <vHRfpJ0QB5YVjDCQhJ-8cwiaOiT_4pf-fddT6sQi6W4=.63b1ebe9-5c96-4572-a44a-7dacbeb846a4@github.com>

On Wed, 9 Feb 2022 23:02:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A simple fix to the test failure by specifying the heap sizes for most of the test cases.
> Before the fix, if the MaxHeapSize is determined by the VM, the MaxHeapSize could become smaller
> than the MinHeapSize or the InitialHeapSize which causing the failure.
> 
> Testing: CI tiers 1 - 4.

LGTM. @tstuefe does this fix the bug for you?

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7413

From shade at openjdk.java.net  Thu Feb 10 07:03:07 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 10 Feb 2022 07:03:07 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <KZrsaSjLWWXW8K1IcPIMV0trxY_i02uW1fCmV2FuzGg=.ac25ef92-fdd5-4ce1-af32-c66c64bdf46b@github.com>

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

All right, but I also keep thinking that NMT becomes a wide-spread diagnostic interface, and at some point in the future we should probably exercise a bit of restraint in introducing overly-fine-grained categories.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7378

From shade at openjdk.java.net  Thu Feb 10 07:08:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 10 Feb 2022 07:08:06 GMT
Subject: RFR: 8281275: Upgrading from 8 to 11 no longer accepts '/' as
 filepath separator in gc paths
In-Reply-To: <Hwe68MFCAH5D5rjbgZX_WqmIRPms0gyGknsd6DUGWvI=.fa3833cf-801b-45e2-b5f4-d1b4a9d396b0@github.com>
References: <Hwe68MFCAH5D5rjbgZX_WqmIRPms0gyGknsd6DUGWvI=.fa3833cf-801b-45e2-b5f4-d1b4a9d396b0@github.com>
Message-ID: <sdy18bOdgki7JkIewOB5jEPl1byFE4MXIkEJt_R6jmU=.f40bb7b3-346c-4065-8b8f-9e5f063e0f01@github.com>

On Thu, 10 Feb 2022 04:53:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix for UL parsing logic on Windows. We already special-cased paths like c:\logfile but didn't allow for c:/logfile. As noted in the bug report this is a regression from using -Xloggc where the c:/ path was allowed (and it even worked when Xloggc was converted internally to use UL - because it skipped the parsing logic and just directly set the file output!).
> 
> Testing:
>   - new gtest added by expanding existing parsing gtest
>   - tiers 1-3 Windows
> 
> Verified that new gtest fails without the fix.
> 
> Thanks,
> David

Looks good.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7415

From dholmes at openjdk.java.net  Thu Feb 10 07:13:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Feb 2022 07:13:05 GMT
Subject: RFR: 8281275: Upgrading from 8 to 11 no longer accepts '/' as
 filepath separator in gc paths
In-Reply-To: <sdy18bOdgki7JkIewOB5jEPl1byFE4MXIkEJt_R6jmU=.f40bb7b3-346c-4065-8b8f-9e5f063e0f01@github.com>
References: <Hwe68MFCAH5D5rjbgZX_WqmIRPms0gyGknsd6DUGWvI=.fa3833cf-801b-45e2-b5f4-d1b4a9d396b0@github.com>
 <sdy18bOdgki7JkIewOB5jEPl1byFE4MXIkEJt_R6jmU=.f40bb7b3-346c-4065-8b8f-9e5f063e0f01@github.com>
Message-ID: <UmvHcpPoiGUf_7ToUCHI5GkNTAvcUIUDUrQURwHzbPw=.b4e225ac-695b-4e20-be5d-22aa3d1f025e@github.com>

On Thu, 10 Feb 2022 07:05:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this trivial fix for UL parsing logic on Windows. We already special-cased paths like c:\logfile but didn't allow for c:/logfile. As noted in the bug report this is a regression from using -Xloggc where the c:/ path was allowed (and it even worked when Xloggc was converted internally to use UL - because it skipped the parsing logic and just directly set the file output!).
>> 
>> Testing:
>>   - new gtest added by expanding existing parsing gtest
>>   - tiers 1-3 Windows
>> 
>> Verified that new gtest fails without the fix.
>> 
>> Thanks,
>> David
>
> Looks good.

Thanks for the review @shipilev !

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

PR: https://git.openjdk.java.net/jdk/pull/7415

From dholmes at openjdk.java.net  Thu Feb 10 07:19:09 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Feb 2022 07:19:09 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <QcZuiUW4UK6SN7GLGWkKpGe32rJhxxr8WdiA0aVPNiI=.d5c53b0c-70f6-4db0-aab5-fd7d6b446c8a@github.com>

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

I'm fine with this as is (modulo Dan's suggested ObjectMonitor change).

I agree with @shipilev that as NMT usage expands we are going to need to more carefully consider how we tag things (and whether we need a way to group tags) so that we can try to address fine- and coarse-grained enquiries.

Cheers,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7378

From stuefe at openjdk.java.net  Thu Feb 10 07:40:05 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 10 Feb 2022 07:40:05 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <v-6f6e_iuPlT0QQI5A9HcpU4i1ojaWuGhWAM1hlh7tU=.5ca67aec-e41a-4039-85bf-3c59aa792995@github.com>

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

Alexey:
> All right, but I also keep thinking that NMT becomes a wide-spread diagnostic interface, and at some point in the future we should probably exercise a bit of restraint in introducing overly-fine-grained categories.

David:
> I'm fine with this as is (modulo Dan's suggested ObjectMonitor change).
> 
> I agree with @shipilev that as NMT usage expands we are going to need to more carefully consider how we tag things (and whether we need a way to group tags) so that we can try to address fine- and coarse-grained inquiries.

I agree with both of you. I feel the situation is a bit like with UL tags. We introduced them, but at some point stopped thinking about rules. At least I am not aware of any rules. The result is a bit anarchic. With NMT it is less severe though since with UL, due to the fact how tags are combined when forming log expressions, once they exist you never can change them. NMT categories have fewer backward compatibility headaches.

The obvious exception are people who compare NMT output between JVM releases and get confused about numbers that changed. But that's just education.

NMT group tags were mentioned several times in other PRs, and I think that makes sense and is not that hard to do. Especially when done at a shallow level, just as a display thing (e.g. log with fine granularity categories a,b,c,d, then define "mtInternal" as a group of a,b,c,d, which only has to interest the NMT printing code).

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From duke at openjdk.java.net  Thu Feb 10 10:12:14 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Thu, 10 Feb 2022 10:12:14 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
 <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
 <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>
 <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>
 <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@github.com>
Message-ID: <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@github.com>

On Mon, 7 Feb 2022 15:10:19 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
> > 
> > 
> > I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
> 
> Thanks for digging out the JBS issue for this.
> 
> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
> > 
> > 
> > I would actually like the following behavior:
> > ```
> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
> > 
> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I think this is close to what we do now.
> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
> > ```
> > * a single 1G page and 256 2m pages for the heap
> > ```
> 
> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
> 
> > ```
> > * 128 2m pages for the code cache
> >   ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
> 
> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
> 
> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
> 
> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?

Hi @kstefanj , @tstuefe 

Thanks for sharing your views and comments. 
Please suggest what specific change you want us to do in the patch since it is fixing the already existing functionality.

Best Regards,
Swati

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From amenkov at openjdk.java.net  Thu Feb 10 12:00:09 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 10 Feb 2022 12:00:09 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times
In-Reply-To: <OWv3zarvAM6dR6eEiX9DNAYWvhndoNShmeJb39V6ViE=.7377d5c4-49fa-493d-9647-8ec58617ed94@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <OWv3zarvAM6dR6eEiX9DNAYWvhndoNShmeJb39V6ViE=.7377d5c4-49fa-493d-9647-8ec58617ed94@github.com>
Message-ID: <bcTUnV_skmEldP11-Z6JstxG7PlYFtRnp3nPEyQozl8=.93572836-aa04-4250-8dfd-04d7e362d290@github.com>

On Wed, 9 Feb 2022 20:17:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> ClassLoaderDataGraph::classes_do description says:
>> // Walking classes through the ClassLoaderDataGraph include array classes.
>> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)
>
> src/hotspot/share/services/heapDumper.cpp line 2293:
> 
>> 2291:     // Writes HPROF_GC_CLASS_DUMP records
>> 2292:     // For array classes we need signers and protection domain from their bottom classes
>> 2293:     // so do_class_dump skips array classes and dumps array classes with corresponding instance class.
> 
> I'm having trouble parsing this comment. Can you clarify?

HPROF_GC_CLASS_DUMP records contain references to signers and protection domain objects.
But this is properties of InstanceKlass, for array classes the properties from their element classes are written (or NULL for arrays of primitive types).
do_class_dump callback skips array classes:
  if (k->is_instance_klass()) {
    DumperSupport::dump_class_and_array_classes(writer(), k);
  }

dump_class_and_array_classes dumps the class and then iterate over array classes (k->array_klass_or_null()) and writes records for them (using signer and protection domain from the instance class specified).

This approach also skips primitive type arrays (they don't have corresponding InstanceKlass) - they are dumped separately.

I added the comment to explain why do_class_dump goes this tricky way.
Do you have any suggestions how to rephrase it to make clearer?

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From amenkov at openjdk.java.net  Thu Feb 10 12:48:41 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 10 Feb 2022 12:48:41 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v2]
In-Reply-To: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
Message-ID: <Mw6oIdcDhhNQn6CFDkE-imuMtBqffX0l8nwEZeSU0TM=.06a3ad89-45a2-49d3-8c78-7b0cd49d7fe1@github.com>

> ClassLoaderDataGraph::classes_do description says:
> // Walking classes through the ClassLoaderDataGraph include array classes.
> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)

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

  updated test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7384/files
  - new: https://git.openjdk.java.net/jdk/pull/7384/files/c227bd68..604b4f88

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From amenkov at openjdk.java.net  Thu Feb 10 12:48:45 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 10 Feb 2022 12:48:45 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v2]
In-Reply-To: <lktIplQUakJqH8pU7XBd6iZpJ8JxJAuQjShx0wo-iTA=.5a401ab7-603d-4668-9aaa-e1790f34420b@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <lktIplQUakJqH8pU7XBd6iZpJ8JxJAuQjShx0wo-iTA=.5a401ab7-603d-4668-9aaa-e1790f34420b@github.com>
Message-ID: <tPg14U8cQJG_UUXCQWV1uNO7Ws_8iuy6xspP6lEc5WA=.a9a0ccee-8375-4506-be42-926ed70396f3@github.com>

On Wed, 9 Feb 2022 19:38:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated test
>
> test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 58:
> 
>> 56:         String[][][] strArray = new String[0][][];
>> 57:         LingeredApp.main(args);
>> 58:         System.out.println("" + intArray + strArray);   // to be sure the classes are not unloaded
> 
> Use  Reference.reachabilityFence(<array>);

Fixed

> test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 86:
> 
>> 84:             Process p = ProcessTools.startProcess("jcmd", new ProcessBuilder(launcher.getCommand()));
>> 85:             // If something goes wrong with heap dumping most likely we'll get crash of the target VM.
>> 86:             while (!p.waitFor(5, TimeUnit.SECONDS)) {
> 
> 5 seconds seems kind of short. Doesn't allow for occasional network hiccups.

Note that this is a cycle. It ensures target VM (theApp) is not terminated while jcmd (p) processes the command.
I had some experience in the past when jcmd didn't exit if target VM crashes.

> test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java line 218:
> 
>> 216:     }
>> 217: 
>> 218:     // Reads the whole HPROF_GC_CLASS_DUMP record, returns closs ID.
> 
> "class ID"

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From vlivanov at openjdk.java.net  Thu Feb 10 17:25:23 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 10 Feb 2022 17:25:23 GMT
Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH
 linkers/invokers
Message-ID: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>

It's another attempt to fix JDK-8256368 (previous one was #1453). 

@coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 

After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.

Original description:

Method linkage of invokehandle instructions involve an upcall into Java
(MethodHandleNatives::linkMethod), but the result is not cached. Unless the
upcall behaves idempotently (which is highly desirable, but not guaranteed),
repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
switching to a higher tier involves call site re-resolution in generated code,
but re-resolution installs a fresh method which puts execution back into
interpreter.

(Another prerequisite is no inlining through a invokehandle which doesn't
normally happen in practice - relevant methods are marked w/ @ForceInline -
except some testing modes, -Xcomp in particular.)

Proposed fix is to inspect ConstantPoolCache first. Previous resolution
attempts from interpreter and C1 records their results there and it stabilises
the execution.

Testing: hs-tier1 - hs-tier4

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

Commit messages:
 - Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers

Changes: https://git.openjdk.java.net/jdk/pull/7429/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7429&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256368
  Stats: 47 lines in 5 files changed: 22 ins; 12 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7429.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7429/head:pull/7429

PR: https://git.openjdk.java.net/jdk/pull/7429

From minqi at openjdk.java.net  Thu Feb 10 20:48:36 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 10 Feb 2022 20:48:36 GMT
Subject: RFR: 8279997: check_for_dynamic_dump should not exit vm
Message-ID: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>

Hi, please review
  When run with -Xshare:auto and the base archive could not be loaded, vm should not exit in DynamicArchive::check_for_dynamic_dump, instead, it should continue without sharing.
  The fix is the run will continue but print out warning to remind user of using -Xlog:cds for more information.

Tests: tier1,tier4

Thanks
Yumin

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

Commit messages:
 - 8279997: check_for_dynamic_dump should not exit vm

Changes: https://git.openjdk.java.net/jdk/pull/7433/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7433&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279997
  Stats: 75 lines in 4 files changed: 38 ins; 15 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7433.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7433/head:pull/7433

PR: https://git.openjdk.java.net/jdk/pull/7433

From dcubed at openjdk.java.net  Thu Feb 10 23:20:08 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 10 Feb 2022 23:20:08 GMT
Subject: RFR: 8281275: Upgrading from 8 to 11 no longer accepts '/' as
 filepath separator in gc paths
In-Reply-To: <Hwe68MFCAH5D5rjbgZX_WqmIRPms0gyGknsd6DUGWvI=.fa3833cf-801b-45e2-b5f4-d1b4a9d396b0@github.com>
References: <Hwe68MFCAH5D5rjbgZX_WqmIRPms0gyGknsd6DUGWvI=.fa3833cf-801b-45e2-b5f4-d1b4a9d396b0@github.com>
Message-ID: <qVs_MPUaNzen3ta-37ul0TBHskGQR5Rs8NwD8j2lUrw=.9263a688-567e-4d15-bc10-c8c942c35ad7@github.com>

On Thu, 10 Feb 2022 04:53:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix for UL parsing logic on Windows. We already special-cased paths like c:\logfile but didn't allow for c:/logfile. As noted in the bug report this is a regression from using -Xloggc where the c:/ path was allowed (and it even worked when Xloggc was converted internally to use UL - because it skipped the parsing logic and just directly set the file output!).
> 
> Testing:
>   - new gtest added by expanding existing parsing gtest
>   - tiers 1-3 Windows
> 
> Verified that new gtest fails without the fix.
> 
> Thanks,
> David

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7415

From dholmes at openjdk.java.net  Thu Feb 10 23:27:10 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Feb 2022 23:27:10 GMT
Subject: RFR: 8281275: Upgrading from 8 to 11 no longer accepts '/' as
 filepath separator in gc paths
In-Reply-To: <qVs_MPUaNzen3ta-37ul0TBHskGQR5Rs8NwD8j2lUrw=.9263a688-567e-4d15-bc10-c8c942c35ad7@github.com>
References: <Hwe68MFCAH5D5rjbgZX_WqmIRPms0gyGknsd6DUGWvI=.fa3833cf-801b-45e2-b5f4-d1b4a9d396b0@github.com>
 <qVs_MPUaNzen3ta-37ul0TBHskGQR5Rs8NwD8j2lUrw=.9263a688-567e-4d15-bc10-c8c942c35ad7@github.com>
Message-ID: <lRI66M7YsA9Y4ckq19m8qynNZgTdnOgUF1d8tASb4DQ=.420cbe43-7525-438d-862d-caa33f818781@github.com>

On Thu, 10 Feb 2022 23:16:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Please review this trivial fix for UL parsing logic on Windows. We already special-cased paths like c:\logfile but didn't allow for c:/logfile. As noted in the bug report this is a regression from using -Xloggc where the c:/ path was allowed (and it even worked when Xloggc was converted internally to use UL - because it skipped the parsing logic and just directly set the file output!).
>> 
>> Testing:
>>   - new gtest added by expanding existing parsing gtest
>>   - tiers 1-3 Windows
>> 
>> Verified that new gtest fails without the fix.
>> 
>> Thanks,
>> David
>
> Thumbs up.

Thanks for the review @dcubed-ojdk !

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

PR: https://git.openjdk.java.net/jdk/pull/7415

From dholmes at openjdk.java.net  Thu Feb 10 23:27:11 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Feb 2022 23:27:11 GMT
Subject: Integrated: 8281275: Upgrading from 8 to 11 no longer accepts '/' as
 filepath separator in gc paths
In-Reply-To: <Hwe68MFCAH5D5rjbgZX_WqmIRPms0gyGknsd6DUGWvI=.fa3833cf-801b-45e2-b5f4-d1b4a9d396b0@github.com>
References: <Hwe68MFCAH5D5rjbgZX_WqmIRPms0gyGknsd6DUGWvI=.fa3833cf-801b-45e2-b5f4-d1b4a9d396b0@github.com>
Message-ID: <Q0SG0BbDwmZ9ErhvS3UOwj2zDEfZQXMuoCn1B8tHbl4=.4eef651c-c3b3-4e71-8c48-3554ebc0d89b@github.com>

On Thu, 10 Feb 2022 04:53:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial fix for UL parsing logic on Windows. We already special-cased paths like c:\logfile but didn't allow for c:/logfile. As noted in the bug report this is a regression from using -Xloggc where the c:/ path was allowed (and it even worked when Xloggc was converted internally to use UL - because it skipped the parsing logic and just directly set the file output!).
> 
> Testing:
>   - new gtest added by expanding existing parsing gtest
>   - tiers 1-3 Windows
> 
> Verified that new gtest fails without the fix.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 84868e39
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/84868e39be4522ba87e603beea0f8da9efa43b6d
Stats:     28 lines in 2 files changed: 23 ins; 0 del; 5 mod

8281275: Upgrading from 8 to 11 no longer accepts '/' as filepath separator in gc paths

Reviewed-by: shade, dcubed

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

PR: https://git.openjdk.java.net/jdk/pull/7415

From ccheung at openjdk.java.net  Fri Feb 11 00:29:32 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Feb 2022 00:29:32 GMT
Subject: RFR: 8223077 module path dynamic archive
Message-ID: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>

Please review this patch for adding module path support for CDS dynamic archive.
Before this patch, if a module path was specified when creating a base archive, the user
won't be able to create a dynamic archive based on the base archive.
VM will issue the following warning:
"Dynamic archiving is disabled because base layer archive has module path"

This patch adds checking of the module patsh in the base archive and the ones specified
for dynamic dumping. If the module paths are the same, dynamic archive will be created.

Testing: tiers 1, 2.

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

Commit messages:
 - add missing files
 - 8223077: Investigate module path support for dynamic CDS archive

Changes: https://git.openjdk.java.net/jdk/pull/7437/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7437&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8223077
  Stats: 176 lines in 6 files changed: 162 ins; 3 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7437/head:pull/7437

PR: https://git.openjdk.java.net/jdk/pull/7437

From ccheung at openjdk.java.net  Fri Feb 11 02:03:08 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Feb 2022 02:03:08 GMT
Subject: RFR: 8279997: check_for_dynamic_dump should not exit vm
In-Reply-To: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>
References: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>
Message-ID: <tLCHGrrrYLILrOE450VNu3TxsBkeAbPoWcsJ9Z6EcYc=.6050e6c9-1d8f-4e6b-a82a-3870d1da2fbf@github.com>

On Thu, 10 Feb 2022 20:40:31 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, please review
>   When run with -Xshare:auto and the base archive could not be loaded, vm should not exit in DynamicArchive::check_for_dynamic_dump, instead, it should continue without sharing.
>   The fix is the run will continue but print out warning to remind user of using -Xlog:cds for more information.
> 
> Tests: tier1,tier4
> 
> Thanks
> Yumin

Looks good. Some nits on the tests.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java line 221:

> 219:             });
> 220: 
> 221:         startTest("10. -XX:SharedArchiveFile=" + topArchiveName + " -XX:ArchiveClassesAtExit=" + getNewArchiveName("top3"));

Should this be `startTest("11. ...` ?

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java line 192:

> 190:             "-XX:+RecordDynamicDumpInfo",
> 191:             "-Xlog:cds+dynamic=debug",
> 192:             "-cp", appJar, mainClass)

This change seems unnecessary.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java line 207:

> 205:             .assertNormalExit(output -> {
> 206:                 output.shouldNotMatch("\\[cds,dynamic");
> 207:                 output.shouldContain("-XX:ArchiveClassesAtExit is unsupported when base CDS archive is not loaded");

You could use the `ERROR` defined at line 199 above.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java line 218:

> 216:             .assertNormalExit(output -> {
> 217:                 output.shouldNotMatch("\\[cds,dynamic");
> 218:                 output.shouldContain("-XX:ArchiveClassesAtExit is unsupported when base CDS archive is not loaded");

You could use the `ERROR` defined at line 199 above.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java line 229:

> 227:                   "-Xlog:cds",
> 228:                   "-cp", appJar, mainClass)
> 229:             .assertAbnormalExit("Cannot use the following option when dumping the shared archive: --patch-module");

This change is unnecessary.

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

PR: https://git.openjdk.java.net/jdk/pull/7433

From dlong at openjdk.java.net  Fri Feb 11 02:29:08 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 11 Feb 2022 02:29:08 GMT
Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH
 linkers/invokers
In-Reply-To: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
References: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
Message-ID: <5JpjYn4xFLnWVCQ-FPp4wN__zUwIZEkW0mm2eIINkcA=.93fe90cf-6bf3-492c-af03-ff0d1d2938e7@github.com>

On Thu, 10 Feb 2022 16:57:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> It's another attempt to fix JDK-8256368 (previous one was #1453). 
> 
> @coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 
> 
> After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
> For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.
> 
> Original description:
> 
> Method linkage of invokehandle instructions involve an upcall into Java
> (MethodHandleNatives::linkMethod), but the result is not cached. Unless the
> upcall behaves idempotently (which is highly desirable, but not guaranteed),
> repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
> switching to a higher tier involves call site re-resolution in generated code,
> but re-resolution installs a fresh method which puts execution back into
> interpreter.
> 
> (Another prerequisite is no inlining through a invokehandle which doesn't
> normally happen in practice - relevant methods are marked w/ @ForceInline -
> except some testing modes, -Xcomp in particular.)
> 
> Proposed fix is to inspect ConstantPoolCache first. Previous resolution
> attempts from interpreter and C1 records their results there and it stabilises
> the execution.
> 
> Testing: hs-tier1 - hs-tier4

Marked as reviewed by dlong (Reviewer).

Looks good.  Is there any reason why we had this optimization for invokedynamic but not invokehandle?

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

PR: https://git.openjdk.java.net/jdk/pull/7429

From minqi at openjdk.java.net  Fri Feb 11 03:25:41 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Feb 2022 03:25:41 GMT
Subject: RFR: 8279997: check_for_dynamic_dump should not exit vm [v2]
In-Reply-To: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>
References: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>
Message-ID: <fjIlvIuHzfW55s4H8oHCg9bhSWp_HEP9dVjO9WSVTQI=.c992d804-fef0-45ac-af27-72b406dddab1@github.com>

> Hi, please review
>   When run with -Xshare:auto and the base archive could not be loaded, vm should not exit in DynamicArchive::check_for_dynamic_dump, instead, it should continue without sharing.
>   The fix is the run will continue but print out warning to remind user of using -Xlog:cds for more information.
> 
> Tests: tier1,tier4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Fixed alignment and order number

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7433/files
  - new: https://git.openjdk.java.net/jdk/pull/7433/files/8c7c63f7..cd7ce49c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7433&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7433&range=00-01

  Stats: 19 lines in 2 files changed: 2 ins; 1 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7433.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7433/head:pull/7433

PR: https://git.openjdk.java.net/jdk/pull/7433

From kvn at openjdk.java.net  Fri Feb 11 03:30:05 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 03:30:05 GMT
Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH
 linkers/invokers
In-Reply-To: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
References: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
Message-ID: <hOnwrRUSK3rkukv6fU-H8vpnhlKF0RArS_2vEgG-ymw=.6d6da3fb-7a8d-450a-9210-12b97cc11188@github.com>

On Thu, 10 Feb 2022 16:57:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> It's another attempt to fix JDK-8256368 (previous one was #1453). 
> 
> @coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 
> 
> After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
> For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.
> 
> Original description:
> 
> Method linkage of invokehandle instructions involve an upcall into Java
> (MethodHandleNatives::linkMethod), but the result is not cached. Unless the
> upcall behaves idempotently (which is highly desirable, but not guaranteed),
> repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
> switching to a higher tier involves call site re-resolution in generated code,
> but re-resolution installs a fresh method which puts execution back into
> interpreter.
> 
> (Another prerequisite is no inlining through a invokehandle which doesn't
> normally happen in practice - relevant methods are marked w/ @ForceInline -
> except some testing modes, -Xcomp in particular.)
> 
> Proposed fix is to inspect ConstantPoolCache first. Previous resolution
> attempts from interpreter and C1 records their results there and it stabilises
> the execution.
> 
> Testing: hs-tier1 - hs-tier4

Marked as reviewed by kvn (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7429

From iklam at openjdk.java.net  Fri Feb 11 06:27:08 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 11 Feb 2022 06:27:08 GMT
Subject: RFR: 8279997: check_for_dynamic_dump should not exit vm [v2]
In-Reply-To: <fjIlvIuHzfW55s4H8oHCg9bhSWp_HEP9dVjO9WSVTQI=.c992d804-fef0-45ac-af27-72b406dddab1@github.com>
References: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>
 <fjIlvIuHzfW55s4H8oHCg9bhSWp_HEP9dVjO9WSVTQI=.c992d804-fef0-45ac-af27-72b406dddab1@github.com>
Message-ID: <Ugdo3tkBujK03Hluuu94uWFPcB9onsU3CfWWiCe6IHA=.fb5824e2-f253-4aff-aec1-57b11b7c45ef@github.com>

On Fri, 11 Feb 2022 03:25:41 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, please review
>>   When run with -Xshare:auto and the base archive could not be loaded, vm should not exit in DynamicArchive::check_for_dynamic_dump, instead, it should continue without sharing.
>>   The fix is the run will continue but print out warning to remind user of using -Xlog:cds for more information.
>> 
>> Tests: tier1,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed alignment and order number

LGTM.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7433

From stuefe at openjdk.java.net  Fri Feb 11 07:24:47 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Feb 2022 07:24:47 GMT
Subject: RFR: JDK-8281460: Let ObjectMonitor have its own NMT category [v2]
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <-e1Ewhioej3Zt89AFiY7NueyVASR3fOsqYpk5xvRIDg=.df62691b-8a35-4cbb-8046-25a1eb7769e2@github.com>

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

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
 - rename category as Dan suggested
 - mtObjectMonitor

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7378/files
  - new: https://git.openjdk.java.net/jdk/pull/7378/files/121811e9..91a2f54a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7378&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7378&range=00-01

  Stats: 8504 lines in 147 files changed: 6385 ins; 1092 del; 1027 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7378/head:pull/7378

PR: https://git.openjdk.java.net/jdk/pull/7378

From stuefe at openjdk.java.net  Fri Feb 11 07:24:49 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Feb 2022 07:24:49 GMT
Subject: Integrated: JDK-8281460: Let ObjectMonitor have its own NMT category
In-Reply-To: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
References: <WX0koe-U9X9sTK5OhhjdzPQeQoOlea16tKY6XuHyhn4=.e385e6f7-086a-477f-b57c-d2363c734ff2@github.com>
Message-ID: <EdFdzmbdWKMr2mkgoD2Vkrgy6qRSSTGAfiSmcR_M34A=.ab53f16d-f447-4ffc-a20d-88fb23a0dcc7@github.com>

On Tue, 8 Feb 2022 08:10:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> It would be useful to distinguish ObjectMonitor allocations in NMT, as a simple way to both to see the needed footprint as well as the number of allocated monitors.
> 
> Note, this needs [JDK-8281450](https://bugs.openjdk.java.net/browse/JDK-8281450) as a prerequisite.

This pull request has now been integrated.

Changeset: a037b3c3
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a037b3c35831f029d23a88bdd49e7f2c2d951631
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8281460: Let ObjectMonitor have its own NMT category

Reviewed-by: dholmes, dcubed, shade

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

PR: https://git.openjdk.java.net/jdk/pull/7378

From iklam at openjdk.java.net  Fri Feb 11 07:26:10 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 11 Feb 2022 07:26:10 GMT
Subject: RFR: 8223077: Investigate module path support for dynamic CDS
 archive
In-Reply-To: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
References: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
Message-ID: <zPrfEwv_x2sLtVeQDdyOE2UVfHVDVaB5wdDVtRDbO84=.f99662f5-dbe5-4a8e-9499-9634dfdfebaa@github.com>

On Fri, 11 Feb 2022 00:21:24 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this patch for adding module path support for CDS dynamic archive.
> Before this patch, if a module path was specified when creating a base archive, the user
> won't be able to create a dynamic archive based on the base archive.
> VM will issue the following warning:
> "Dynamic archiving is disabled because base layer archive has module path"
> 
> This patch adds checking of the module patsh in the base archive and the ones specified
> for dynamic dumping. If the module paths are the same, dynamic archive will be created.
> 
> Testing: tiers 1, 2.

LGTM. Instead of "investigate ...", I think the name of the issue should describe the change.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7437

From vlivanov at openjdk.java.net  Fri Feb 11 10:21:05 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 11 Feb 2022 10:21:05 GMT
Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH
 linkers/invokers
In-Reply-To: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
References: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
Message-ID: <JP9U1gVxEHsAmUvJt7u8NWPPL1NNzKLAzRinQnivx3o=.7e3e5e15-7e70-4cdc-a5ca-e81ce1b8b726@github.com>

On Thu, 10 Feb 2022 16:57:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> It's another attempt to fix JDK-8256368 (previous one was #1453). 
> 
> @coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 
> 
> After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
> For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.
> 
> Original description:
> 
> Method linkage of invokehandle instructions involve an upcall into Java
> (MethodHandleNatives::linkMethod), but the result is not cached. Unless the
> upcall behaves idempotently (which is highly desirable, but not guaranteed),
> repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
> switching to a higher tier involves call site re-resolution in generated code,
> but re-resolution installs a fresh method which puts execution back into
> interpreter.
> 
> (Another prerequisite is no inlining through a invokehandle which doesn't
> normally happen in practice - relevant methods are marked w/ @ForceInline -
> except some testing modes, -Xcomp in particular.)
> 
> Proposed fix is to inspect ConstantPoolCache first. Previous resolution
> attempts from interpreter and C1 records their results there and it stabilises
> the execution.
> 
> Testing: hs-tier1 - hs-tier4

Thanks for the reviews, Vladimir and Dean.

> Is there any reason why we had this optimization for invokedynamic but not invokehandle?

It's optional for `invokehandle`, but mandatory for `invokedynamic`. 

`invokedynamic` can be linked by arbitrary user code (as part of bootstrap method execution) and calling BSM multiple times would violate the JVMS. There are no guarantees about BSM behavior, so it can produce different results on repeated invocations. 

In contrast, `invokehandle` is linked solely by trusted code (`MethodHandleNatives.linkMethod`) and it's fine to re-resolve the call site on failure (`LinkageError`), since the result should be the same (unless it was an intermittent JVM failure, like OOM or StackOverflowError).

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

PR: https://git.openjdk.java.net/jdk/pull/7429

From sjohanss at openjdk.java.net  Fri Feb 11 14:55:06 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 11 Feb 2022 14:55:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <U4pT9VEgQvzLazRsds9_Jo_CMXLvRzFqz7Y3sVpqoog=.1547aa2e-ef18-48c6-b55e-b273f0d85ea1@github.com>

On Fri, 4 Feb 2022 12:50:49 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

I would actually say this is adding new functionality. We have never had any fallback to smaller large page sizes if the configured one is not working properly. What we do have support for is to use smaller large page sizes for mappings that are smaller than the configured large page size. As we have discussed above, there is room for improvement in this area and I'm starting to think that moving towards something where `os::large_page_size()` is not even used should be the end goal. But as a first step, falling back to use smaller pages sizes is good.

To be more concrete about your patch, as I've said before, I would prefer a solution like the one I proposed above. Sure the heap might be aligned to something larger than what the final large page size require, but I don't think that's a very big issue since there will be quite few of these mappings (and again the user/administrator requested this alignment). Also, going with something like my suggestion above will cover more cases. For example, your proposed solution won't work if there is ONE 1G page available but not TWO. In this case the sanity check will pass, but your heap reservation will fail. 

I did spend some more time on my proposal to improve the logging and warnings a bit. Could probably be improved even further but you can take a look here to see the current state:
https://github.com/openjdk/jdk/compare/master...kstefanj:8271195-lp-fallback

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From ccheung at openjdk.java.net  Fri Feb 11 16:13:10 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Feb 2022 16:13:10 GMT
Subject: RFR: 8279997: check_for_dynamic_dump should not exit vm [v2]
In-Reply-To: <fjIlvIuHzfW55s4H8oHCg9bhSWp_HEP9dVjO9WSVTQI=.c992d804-fef0-45ac-af27-72b406dddab1@github.com>
References: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>
 <fjIlvIuHzfW55s4H8oHCg9bhSWp_HEP9dVjO9WSVTQI=.c992d804-fef0-45ac-af27-72b406dddab1@github.com>
Message-ID: <0Wxsz3TKTNm6wHHxnebSSdZYns-HobFzs0vTt0MfXdw=.be6975fa-7e48-4cad-a142-589159911021@github.com>

On Fri, 11 Feb 2022 03:25:41 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, please review
>>   When run with -Xshare:auto and the base archive could not be loaded, vm should not exit in DynamicArchive::check_for_dynamic_dump, instead, it should continue without sharing.
>>   The fix is the run will continue but print out warning to remind user of using -Xlog:cds for more information.
>> 
>> Tests: tier1,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed alignment and order number

Updated webrev looks good.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7433

From minqi at openjdk.java.net  Fri Feb 11 16:40:08 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Feb 2022 16:40:08 GMT
Subject: RFR: 8223077: Investigate module path support for dynamic CDS
 archive
In-Reply-To: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
References: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
Message-ID: <tfzHjUWBe_nxuIqjntzXBmHWKZuubycMrsLP2Q4cGnM=.63700cc6-55b3-4743-a4b5-b370319f5612@github.com>

On Fri, 11 Feb 2022 00:21:24 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this patch for adding module path support for CDS dynamic archive.
> Before this patch, if a module path was specified when creating a base archive, the user
> won't be able to create a dynamic archive based on the base archive.
> VM will issue the following warning:
> "Dynamic archiving is disabled because base layer archive has module path"
> 
> This patch adds checking of the module patsh in the base archive and the ones specified
> for dynamic dumping. If the module paths are the same, dynamic archive will be created.
> 
> Testing: tiers 1, 2.

LGTM
TestCommon.java and UnsupportedBaseArchive.java need copyright year update.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7437

From minqi at openjdk.java.net  Fri Feb 11 16:43:09 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Feb 2022 16:43:09 GMT
Subject: RFR: 8279997: check_for_dynamic_dump should not exit vm [v2]
In-Reply-To: <0Wxsz3TKTNm6wHHxnebSSdZYns-HobFzs0vTt0MfXdw=.be6975fa-7e48-4cad-a142-589159911021@github.com>
References: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>
 <fjIlvIuHzfW55s4H8oHCg9bhSWp_HEP9dVjO9WSVTQI=.c992d804-fef0-45ac-af27-72b406dddab1@github.com>
 <0Wxsz3TKTNm6wHHxnebSSdZYns-HobFzs0vTt0MfXdw=.be6975fa-7e48-4cad-a142-589159911021@github.com>
Message-ID: <V8DOnHDQwwHXiKkbQgVfWTn9prx6swVYeaahfsTBlAY=.ddabfbec-82e4-4219-a029-5efabc5ebe7e@github.com>

On Fri, 11 Feb 2022 16:10:03 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed alignment and order number
>
> Updated webrev looks good.

@calvinccheung @iklam Thanks for review!

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

PR: https://git.openjdk.java.net/jdk/pull/7433

From minqi at openjdk.java.net  Fri Feb 11 16:45:08 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Feb 2022 16:45:08 GMT
Subject: Integrated: 8279997: check_for_dynamic_dump should not exit vm
In-Reply-To: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>
References: <dWV4yfN66YXTPKAAfmO6J8eKScQBgUro_4MHJjbt46A=.42991d7d-63b2-4c6f-a910-47d2d43a01bc@github.com>
Message-ID: <7v0UXgBUUGZ5YQFuwnM2eviB0nWxT4wXxahgEb5bHIk=.699f609c-ac45-41d3-96db-731bf6eb0bed@github.com>

On Thu, 10 Feb 2022 20:40:31 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, please review
>   When run with -Xshare:auto and the base archive could not be loaded, vm should not exit in DynamicArchive::check_for_dynamic_dump, instead, it should continue without sharing.
>   The fix is the run will continue but print out warning to remind user of using -Xlog:cds for more information.
> 
> Tests: tier1,tier4
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: e75e8cd7
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e75e8cd708ed478eda08c4a5c724e7e82f57d36e
Stats:     66 lines in 4 files changed: 36 ins; 12 del; 18 mod

8279997: check_for_dynamic_dump should not exit vm

Reviewed-by: ccheung, iklam

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

PR: https://git.openjdk.java.net/jdk/pull/7433

From ccheung at openjdk.java.net  Fri Feb 11 16:59:55 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Feb 2022 16:59:55 GMT
Subject: RFR: 8223077: Investigate module path support for dynamic CDS
 archive [v2]
In-Reply-To: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
References: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
Message-ID: <l0Rf4_EZCDg1gq9I_PNRx7fKvG86wCctYWOOIBnhOjY=.7d8cb193-85f4-4c0c-b4a3-284ecc369cf4@github.com>

> Please review this patch for adding module path support for CDS dynamic archive.
> Before this patch, if a module path was specified when creating a base archive, the user
> won't be able to create a dynamic archive based on the base archive.
> VM will issue the following warning:
> "Dynamic archiving is disabled because base layer archive has module path"
> 
> This patch adds checking of the module patsh in the base archive and the ones specified
> for dynamic dumping. If the module paths are the same, dynamic archive will be created.
> 
> Testing: tiers 1, 2.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7437/files
  - new: https://git.openjdk.java.net/jdk/pull/7437/files/fe11eb6d..ab48afae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7437&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7437&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7437

From ccheung at openjdk.java.net  Fri Feb 11 17:26:14 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Feb 2022 17:26:14 GMT
Subject: RFR: 8223077: module path support for dynamic CDS archive [v2]
In-Reply-To: <zPrfEwv_x2sLtVeQDdyOE2UVfHVDVaB5wdDVtRDbO84=.f99662f5-dbe5-4a8e-9499-9634dfdfebaa@github.com>
References: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
 <zPrfEwv_x2sLtVeQDdyOE2UVfHVDVaB5wdDVtRDbO84=.f99662f5-dbe5-4a8e-9499-9634dfdfebaa@github.com>
Message-ID: <rWGV9n6Z7CG6smiID371_J3eleqhIdDANoFBqTGK0qI=.136d5ad8-2358-49ba-a0b2-b7b16a3e44de@github.com>

On Fri, 11 Feb 2022 07:22:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> LGTM. Instead of "investigate ...", I think the name of the issue should describe the change.

Thanks for the review. I've dropped the word "Investigate" from the title.

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

PR: https://git.openjdk.java.net/jdk/pull/7437

From ccheung at openjdk.java.net  Fri Feb 11 17:26:15 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Feb 2022 17:26:15 GMT
Subject: RFR: 8223077: module path support for dynamic CDS archive [v2]
In-Reply-To: <tfzHjUWBe_nxuIqjntzXBmHWKZuubycMrsLP2Q4cGnM=.63700cc6-55b3-4743-a4b5-b370319f5612@github.com>
References: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
 <tfzHjUWBe_nxuIqjntzXBmHWKZuubycMrsLP2Q4cGnM=.63700cc6-55b3-4743-a4b5-b370319f5612@github.com>
Message-ID: <QfriqvpRlvXQ6x0p-WElNdPip4iC4gwCgPFuhHl50Wg=.cb1b2187-60b2-4bef-a0a5-7759da7f8fb7@github.com>

On Fri, 11 Feb 2022 16:36:42 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> LGTM
> TestCommon.java and UnsupportedBaseArchive.java need copyright year update.

Thanks for the review. Copyright year updated.

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

PR: https://git.openjdk.java.net/jdk/pull/7437

From minqi at openjdk.java.net  Fri Feb 11 17:34:13 2022
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Feb 2022 17:34:13 GMT
Subject: RFR: 8223077: module path support for dynamic CDS archive [v2]
In-Reply-To: <l0Rf4_EZCDg1gq9I_PNRx7fKvG86wCctYWOOIBnhOjY=.7d8cb193-85f4-4c0c-b4a3-284ecc369cf4@github.com>
References: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
 <l0Rf4_EZCDg1gq9I_PNRx7fKvG86wCctYWOOIBnhOjY=.7d8cb193-85f4-4c0c-b4a3-284ecc369cf4@github.com>
Message-ID: <ht8eFPxmUvagsKLWsWvw-bUUdYIG0BxLzm65xbz53VM=.b6d29dc2-6261-4d6c-b847-53ffe0262917@github.com>

On Fri, 11 Feb 2022 16:59:55 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this patch for adding module path support for CDS dynamic archive.
>> Before this patch, if a module path was specified when creating a base archive, the user
>> won't be able to create a dynamic archive based on the base archive.
>> VM will issue the following warning:
>> "Dynamic archiving is disabled because base layer archive has module path"
>> 
>> This patch adds checking of the module patsh in the base archive and the ones specified
>> for dynamic dumping. If the module paths are the same, dynamic archive will be created.
>> 
>> Testing: tiers 1, 2.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Change LG.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7437

From ccheung at openjdk.java.net  Fri Feb 11 17:43:10 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 11 Feb 2022 17:43:10 GMT
Subject: Integrated: 8223077: module path support for dynamic CDS archive
In-Reply-To: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
References: <mO6-b7z3NGXLwBm9Svo-93JGxmoEb57iwa1wbgE8x3Q=.5ebff717-308f-46c4-8c35-767729afa99f@github.com>
Message-ID: <XI5mRNfsIhAj11B6VDQf6aa2CxoB9amaGnR5leHX2IY=.1ce90600-2f82-46af-859b-efedd2539644@github.com>

On Fri, 11 Feb 2022 00:21:24 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this patch for adding module path support for CDS dynamic archive.
> Before this patch, if a module path was specified when creating a base archive, the user
> won't be able to create a dynamic archive based on the base archive.
> VM will issue the following warning:
> "Dynamic archiving is disabled because base layer archive has module path"
> 
> This patch adds checking of the module patsh in the base archive and the ones specified
> for dynamic dumping. If the module paths are the same, dynamic archive will be created.
> 
> Testing: tiers 1, 2.

This pull request has now been integrated.

Changeset: c5ff6e45
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c5ff6e45dee41b5703138d323a04c2c7973a08b9
Stats:     178 lines in 6 files changed: 162 ins; 3 del; 13 mod

8223077: module path support for dynamic CDS archive

Reviewed-by: iklam, minqi

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

PR: https://git.openjdk.java.net/jdk/pull/7437

From duke at openjdk.java.net  Fri Feb 11 23:59:14 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 11 Feb 2022 23:59:14 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <N5geXLEn8vaODaHSwb-MqnngHDUgg1BAJMwB-iIx4Gk=.1641fafb-1721-4cd3-b781-36600db7760e@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>
 <N5geXLEn8vaODaHSwb-MqnngHDUgg1BAJMwB-iIx4Gk=.1641fafb-1721-4cd3-b781-36600db7760e@github.com>
Message-ID: <VRwNaccQWMLV2ECiQfcDYrjqCK2ZoNDjoz_svgrgi7o=.bb51a28f-d405-4bf1-b617-a920fd0ff366@github.com>

On Fri, 4 Feb 2022 16:17:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Be warned: This may take time. You certainly want your change to get integrated at some point of time.

I think this has turned out to be sage advice from Martin, as I believe neither of us has received a reply from the Oracle copyright advisor. In the interests of completing this change, I would be happy to move forward with either of the following.

1. The suggestion from IBM legal department to add both Oracle, and IBM copyright lines (with IBM lines only added to files with significant modification, as discussed above).
2. Reverting copyright header modifications other than year updates.

What are you most comfortable with, my sterling team of reviewers?

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From dholmes at openjdk.java.net  Sat Feb 12 14:16:33 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 12 Feb 2022 14:16:33 GMT
Subject: Integrated: 8281675: VMDeprecatedOptions test fails after JDK-8278423
Message-ID: <CnkcFaFlSPZCuvjaw6zQjsr7zcY8xFvt-KTT9m9iPPA=.0ee4ed41-d0aa-4b34-81a8-516c275f0bd7@github.com>

Please review this trivial reverting of the change to the VMDeprecatedOptions test. We can't determine if DTrace is enabled so we just don't check the ExtendedDTraceProbes flag.

Testing: local testing of reverted test.

Thanks,
David

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

Commit messages:
 - 8281675: VMDeprecatedOptions test fails after JDK-8278423

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

PR: https://git.openjdk.java.net/jdk/pull/7452

From dcubed at openjdk.java.net  Sat Feb 12 14:16:34 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 12 Feb 2022 14:16:34 GMT
Subject: Integrated: 8281675: VMDeprecatedOptions test fails after
 JDK-8278423
In-Reply-To: <CnkcFaFlSPZCuvjaw6zQjsr7zcY8xFvt-KTT9m9iPPA=.0ee4ed41-d0aa-4b34-81a8-516c275f0bd7@github.com>
References: <CnkcFaFlSPZCuvjaw6zQjsr7zcY8xFvt-KTT9m9iPPA=.0ee4ed41-d0aa-4b34-81a8-516c275f0bd7@github.com>
Message-ID: <Yf1c44k5ZEc3yuVT31SjXJTvltLYrw4ROPqomP4tTro=.9d2cfed6-191e-4ea9-a12b-d2e50abda4ce@github.com>

On Sat, 12 Feb 2022 14:07:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial reverting of the change to the VMDeprecatedOptions test. We can't determine if DTrace is enabled so we just don't check the ExtendedDTraceProbes flag.
> 
> Testing: local testing of reverted test.
> 
> Thanks,
> David

Thumbs up. I agree that this is a trivial fix.

test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 57:

> 55:             {"TLABStats",                 "false"},
> 56:             {"AllowRedefinitionToAddDeleteMethods", "true"},
> 57:             {"ExtendedDTraceProbes", "true"},

Do you want to add a comment that this flag cannot be tested at this time?

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7452

From dholmes at openjdk.java.net  Sat Feb 12 14:16:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 12 Feb 2022 14:16:36 GMT
Subject: Integrated: 8281675: VMDeprecatedOptions test fails after
 JDK-8278423
In-Reply-To: <Yf1c44k5ZEc3yuVT31SjXJTvltLYrw4ROPqomP4tTro=.9d2cfed6-191e-4ea9-a12b-d2e50abda4ce@github.com>
References: <CnkcFaFlSPZCuvjaw6zQjsr7zcY8xFvt-KTT9m9iPPA=.0ee4ed41-d0aa-4b34-81a8-516c275f0bd7@github.com>
 <Yf1c44k5ZEc3yuVT31SjXJTvltLYrw4ROPqomP4tTro=.9d2cfed6-191e-4ea9-a12b-d2e50abda4ce@github.com>
Message-ID: <0Lm6zY7DvG5AmzophuXSvx4wLN5Nmu3xIFPsKCsa7lU=.4b198dfb-6489-440b-9ea9-0de1c01bd33c@github.com>

On Sat, 12 Feb 2022 14:08:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Please review this trivial reverting of the change to the VMDeprecatedOptions test. We can't determine if DTrace is enabled so we just don't check the ExtendedDTraceProbes flag.
>> 
>> Testing: local testing of reverted test.
>> 
>> Thanks,
>> David
>
> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 57:
> 
>> 55:             {"TLABStats",                 "false"},
>> 56:             {"AllowRedefinitionToAddDeleteMethods", "true"},
>> 57:             {"ExtendedDTraceProbes", "true"},
> 
> Do you want to add a comment that this flag cannot be tested at this time?

Not really. It doesn't really make sense to me to comment something that isn't there - and then we'd have to remember to remove the comment again next release.

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

PR: https://git.openjdk.java.net/jdk/pull/7452

From dholmes at openjdk.java.net  Sat Feb 12 14:16:37 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 12 Feb 2022 14:16:37 GMT
Subject: Integrated: 8281675: VMDeprecatedOptions test fails after JDK-8278423
In-Reply-To: <CnkcFaFlSPZCuvjaw6zQjsr7zcY8xFvt-KTT9m9iPPA=.0ee4ed41-d0aa-4b34-81a8-516c275f0bd7@github.com>
References: <CnkcFaFlSPZCuvjaw6zQjsr7zcY8xFvt-KTT9m9iPPA=.0ee4ed41-d0aa-4b34-81a8-516c275f0bd7@github.com>
Message-ID: <4ytC9OaH3myadn0toounCcwlF7jXrv3WG4CSvtet8rI=.bd0c41e7-e2fd-47fb-a998-65f7c1bc9b37@github.com>

On Sat, 12 Feb 2022 14:07:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial reverting of the change to the VMDeprecatedOptions test. We can't determine if DTrace is enabled so we just don't check the ExtendedDTraceProbes flag.
> 
> Testing: local testing of reverted test.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 8acfbc2e
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8acfbc2e21063c3dc088c25c1574bcefa94e5a24
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8281675: VMDeprecatedOptions test fails after JDK-8278423

Reviewed-by: dcubed

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

PR: https://git.openjdk.java.net/jdk/pull/7452

From lmesnik at openjdk.java.net  Sat Feb 12 22:13:28 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sat, 12 Feb 2022 22:13:28 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
Message-ID: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>

Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.

Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.

Thanks to Vladimir I.  for finding exact root cause of problem.

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

Commit messages:
 - 8279949: JavaThread::_free_handle_block leaks native memory

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From dholmes at openjdk.java.net  Sun Feb 13 01:53:02 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 13 Feb 2022 01:53:02 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
Message-ID: <OD-SE94GUOzPMGUaqFkpxOH1FYqkGHJIqYj3TXvItKQ=.f91765bb-bef5-4596-8af2-109c98bda077@github.com>

On Sat, 12 Feb 2022 22:07:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
> 
> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
> 
> Thanks to Vladimir I.  for finding exact root cause of problem.

Hi Leonid,

I can't help but think the real problem here is that some code is not managing the active handles correctly. AFAICS we should not end up with a chain of handle blocks when a thread exits! The JVMTI push_frame/pop_frame logic looks a bit messy in that regard - it isn't clear if these are allowed to be unbalanced.

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From dholmes at openjdk.java.net  Sun Feb 13 01:57:02 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 13 Feb 2022 01:57:02 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
Message-ID: <hfnCStOaMgTUustGCLMwNJwby6TeAenuZaLGBzxYJCk=.bd6eea68-8575-4e1d-8754-6224e93d9dd4@github.com>

On Sat, 12 Feb 2022 22:07:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
> 
> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
> 
> Thanks to Vladimir I.  for finding exact root cause of problem.

Correction JNI pushLocalFrame/popLocalFrame, not JVM TI.

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From dholmes at openjdk.java.net  Sun Feb 13 02:00:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 13 Feb 2022 02:00:04 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
Message-ID: <4zr6kEgiVV97kOxCDDoepUMOnlgHCCpXDHWLqUYFC80=.92be6e30-41cc-459f-9729-ca38c3a17e4b@github.com>

On Sat, 12 Feb 2022 22:07:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
> 
> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
> 
> Thanks to Vladimir I.  for finding exact root cause of problem.

On further examination it seems we can't guarantee balanced use so cleaning up at thread exit does seem the right approach.

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From dholmes at openjdk.java.net  Sun Feb 13 02:09:01 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 13 Feb 2022 02:09:01 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
Message-ID: <SNWQJdx_9C-ExLN0tsDxQuoqcMxL8XC29Yb6pMQn55M=.7b1d37d1-fd83-43bf-8a11-7db5d0ad1c02@github.com>

On Sat, 12 Feb 2022 22:07:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
> 
> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
> 
> Thanks to Vladimir I.  for finding exact root cause of problem.

Sorry Leonid,

I think we need to understand exactly how we end up with a chain of blocks at thread exit - see comment below.

David

src/hotspot/share/runtime/jniHandles.cpp line 395:

> 393:       delete block;
> 394:       block = next;
> 395:     }

Given the comment below about the `pop_frame_link`, I'm concerned that it may be possible that the loop above has deleted the block that `pop_frame_link` refers to. AFAICS we should only have a chain above if we have unbalanced `pushLocalFrame`/`popLocalFrame`, but that is the case the following code is trying to deal with too.

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From dholmes at openjdk.java.net  Sun Feb 13 02:19:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 13 Feb 2022 02:19:05 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <SNWQJdx_9C-ExLN0tsDxQuoqcMxL8XC29Yb6pMQn55M=.7b1d37d1-fd83-43bf-8a11-7db5d0ad1c02@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
 <SNWQJdx_9C-ExLN0tsDxQuoqcMxL8XC29Yb6pMQn55M=.7b1d37d1-fd83-43bf-8a11-7db5d0ad1c02@github.com>
Message-ID: <VJfbFYq492jnKG6U59LFtBHn0gz8IucMHN4cuqnCoc4=.24cdce58-9e3a-467d-82b0-a7a47f38dfdb@github.com>

On Sun, 13 Feb 2022 02:05:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
>> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
>> 
>> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
>> 
>> Thanks to Vladimir I.  for finding exact root cause of problem.
>
> src/hotspot/share/runtime/jniHandles.cpp line 395:
> 
>> 393:       delete block;
>> 394:       block = next;
>> 395:     }
> 
> Given the comment below about the `pop_frame_link`, I'm concerned that it may be possible that the loop above has deleted the block that `pop_frame_link` refers to. AFAICS we should only have a chain above if we have unbalanced `pushLocalFrame`/`popLocalFrame`, but that is the case the following code is trying to deal with too.

I see the bug report indicates the problem is with a chain of blocks in the free-list - something which again seems to indicate unbalanced use. But the fix doesn't just change the free-list handling, it also changes the active-list handling.

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From vlivanov at openjdk.java.net  Sun Feb 13 19:10:10 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Sun, 13 Feb 2022 19:10:10 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <SNWQJdx_9C-ExLN0tsDxQuoqcMxL8XC29Yb6pMQn55M=.7b1d37d1-fd83-43bf-8a11-7db5d0ad1c02@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
 <SNWQJdx_9C-ExLN0tsDxQuoqcMxL8XC29Yb6pMQn55M=.7b1d37d1-fd83-43bf-8a11-7db5d0ad1c02@github.com>
Message-ID: <YzUynXCAXDfQsszZeQ5ytBvjHlP94ElySt3vHLwNPaw=.e249edb9-2684-48cf-af50-5cabf23085fa@github.com>

On Sun, 13 Feb 2022 02:05:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>  think we need to understand exactly how we end up with a chain of blocks at thread exit 

My understanding is `JNIHandleBlock` is allocated on every upcall from VM to Java code (it's part of `JavaCallWrapper` ctor). Since it is possible to have "nested" upcalls (Java -> VM -> Java -> VM), there are multiple thread-local blocks allocated and they eventually end up on the free list.

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From dholmes at openjdk.java.net  Sun Feb 13 22:27:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 13 Feb 2022 22:27:05 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <YzUynXCAXDfQsszZeQ5ytBvjHlP94ElySt3vHLwNPaw=.e249edb9-2684-48cf-af50-5cabf23085fa@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
 <SNWQJdx_9C-ExLN0tsDxQuoqcMxL8XC29Yb6pMQn55M=.7b1d37d1-fd83-43bf-8a11-7db5d0ad1c02@github.com>
 <YzUynXCAXDfQsszZeQ5ytBvjHlP94ElySt3vHLwNPaw=.e249edb9-2684-48cf-af50-5cabf23085fa@github.com>
Message-ID: <f696w3ZKebJPsId_Hd8AsXRoDpxWXVeY1HXPJVOBDHc=.4194ed37-f432-4b29-b319-6f2d8263bcea@github.com>

On Sun, 13 Feb 2022 19:07:02 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Sorry Leonid,
>> 
>> I think we need to understand exactly how we end up with a chain of blocks at thread exit - see comment below.
>> 
>> David
>
>>  think we need to understand exactly how we end up with a chain of blocks at thread exit 
> 
> My understanding is `JNIHandleBlock` is allocated on every upcall from VM to Java code (it's part of `JavaCallWrapper` ctor). Since it is possible to have "nested" upcalls (Java -> VM -> Java -> VM), there are multiple thread-local blocks allocated and they eventually end up on the free list.

@iwanowww  Right for the free-list case this is expected if there are nested upcalls. So that is normal - my mistake for thinking it needed unbalanced use. So happy to see that free-list get recursively deleted.

But still concerned there may be some unexpected interaction with pop_frame_link when the active-list is cleared.

Simplest solution would be to introduce a new method that clears recursively and use that for the free-list case. Still leaves unanswered questions about the active-list, but wouldn't change any behaviour there.

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From lmesnik at openjdk.java.net  Sun Feb 13 23:43:00 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sun, 13 Feb 2022 23:43:00 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
Message-ID: <EXQ4VYUBdRloyHy4K9yofHSWP7SPHWEz4AsadCMRWFM=.482ca57f-8087-4cd4-8f19-d797087ae95a@github.com>

On Sat, 12 Feb 2022 22:07:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
> 
> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
> 
> Thanks to Vladimir I.  for finding exact root cause of problem.

I agree that JNIHandleBlocks are a little bit unclear and might need some explanation.

The active_list is organized as list of lists of JNIHandleBlocks:
block->_next->_next....
|
_pop_frame_link
|
block->_next->_next...

so the only fist block could have non-NULL _pop_frame_link and refer to the first block in the list. See class JNIHandleBlock

  // The following instance variables are only used by the first block in a chain.
  // Having two types of blocks complicates the code and the space overhead in negligible.
  JNIHandleBlock* _last;                        // Last block in use
  JNIHandleBlock* _pop_frame_link;              // Block to restore on PopLocalFrame call
  uintptr_t*      _free_list;                   // Handle free list


The function  release_block() deletes (or return to _free_handle_block) the list block->_next->_next.. and recursively calls itself for next frame. 

The  JNIHandleBlock referred with _next never might be referred with  _pop_frame_link  and cloud be safely deleted. My assertion just check that only first block refer to other frame.

It might be simpler to have
JNIHandleBlockFrame which is list of JNIHandleBlock and also have a pointer _pop_frame_link to other chain to avoid mess with _next and _pop_frame_link pointers.

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From dholmes at openjdk.java.net  Mon Feb 14 00:48:03 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Feb 2022 00:48:03 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
Message-ID: <kGzqm0gH_k3MR_R-smsPHmsjn5-VfA7I03E83TUAhac=.ebaa32d5-e8d4-41a4-b718-46b6ff941569@github.com>

On Sat, 12 Feb 2022 22:07:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
> 
> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
> 
> Thanks to Vladimir I.  for finding exact root cause of problem.

Marked as reviewed by dholmes (Reviewer).

Leonid has pointed out how the bug was introduced by JDK-8276658. Previously `release_block` would either add a chain of blocks to the thread-local freelist, or the global freelist. After JDK-8276658 it would either add a chain of blocks to the thread-local freelist or delete the first block in the chain - hence the current bug.

IIUC now, `_pop_frame_link`  if non-null, points to a completely distinct chain of blocks that was saved as part of `pushLocalFrame` and so can never point to a block which has just been deleted.

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From cjplummer at openjdk.java.net  Mon Feb 14 05:06:09 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 14 Feb 2022 05:06:09 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v2]
In-Reply-To: <bcTUnV_skmEldP11-Z6JstxG7PlYFtRnp3nPEyQozl8=.93572836-aa04-4250-8dfd-04d7e362d290@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <OWv3zarvAM6dR6eEiX9DNAYWvhndoNShmeJb39V6ViE=.7377d5c4-49fa-493d-9647-8ec58617ed94@github.com>
 <bcTUnV_skmEldP11-Z6JstxG7PlYFtRnp3nPEyQozl8=.93572836-aa04-4250-8dfd-04d7e362d290@github.com>
Message-ID: <Hsb0o5RPH5NGRPsCvyIjj4YjG5PK_MfEKWYKxr38T1A=.2293c93b-9259-4de2-86aa-45d2afe3e5fb@github.com>

On Thu, 10 Feb 2022 11:57:25 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/services/heapDumper.cpp line 2293:
>> 
>>> 2291:     // Writes HPROF_GC_CLASS_DUMP records
>>> 2292:     // For array classes we need signers and protection domain from their bottom classes
>>> 2293:     // so do_class_dump skips array classes and dumps array classes with corresponding instance class.
>> 
>> I'm having trouble parsing this comment. Can you clarify?
>
> HPROF_GC_CLASS_DUMP records contain references to signers and protection domain objects.
> But this is properties of InstanceKlass, for array classes the properties from their element classes are written (or NULL for arrays of primitive types).
> do_class_dump callback skips array classes:
>   if (k->is_instance_klass()) {
>     DumperSupport::dump_class_and_array_classes(writer(), k);
>   }
> 
> dump_class_and_array_classes dumps the class and then iterate over array classes (k->array_klass_or_null()) and writes records for them (using signer and protection domain from the instance class specified).
> 
> This approach also skips primitive type arrays (they don't have corresponding InstanceKlass) - they are dumped separately.
> 
> I added the comment to explain why do_class_dump goes this tricky way.
> Do you have any suggestions how to rephrase it to make clearer?

Sorry about the delay. I didn't see your response when it came in.

It seems like this comment belongs with do_class_dump(). Putting it here is kind of confusing. Also, what is meant by "bottom class"? Do you mean the element type of the array?

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From iklam at openjdk.java.net  Mon Feb 14 07:45:35 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 14 Feb 2022 07:45:35 GMT
Subject: RFR: 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails
 after JDK-8279997
Message-ID: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>

Please review this trivial change - the two new test cases added in JDK-8279997 do not work when the tests are executed with `jtreg -vmoptions:-Xshare:off`. This patch disable the two test cases under such condition to avoid causing CI failures

A proper fix will be done in https://bugs.openjdk.java.net/browse/JDK-8281715

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

Commit messages:
 - 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails after JDK-8279997

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

PR: https://git.openjdk.java.net/jdk/pull/7457

From stuefe at openjdk.java.net  Mon Feb 14 07:52:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 07:52:15 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <VRwNaccQWMLV2ECiQfcDYrjqCK2ZoNDjoz_svgrgi7o=.bb51a28f-d405-4bf1-b617-a920fd0ff366@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <tyApS0ubkc2Fa_HTxMfi7iF-56ZdZF0m3bkC3nq3kYs=.5ee73b38-cf22-4022-a423-8275baddeaac@github.com>
 <N5geXLEn8vaODaHSwb-MqnngHDUgg1BAJMwB-iIx4Gk=.1641fafb-1721-4cd3-b781-36600db7760e@github.com>
 <VRwNaccQWMLV2ECiQfcDYrjqCK2ZoNDjoz_svgrgi7o=.bb51a28f-d405-4bf1-b617-a920fd0ff366@github.com>
Message-ID: <aIq2iCa6NySxJYwAO_D20CIjTWtNJRSI4akO6Fmv60w=.f0c719f7-2c05-4974-925d-46a5c19a271f@github.com>

On Fri, 11 Feb 2022 23:56:19 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> > Be warned: This may take time. You certainly want your change to get integrated at some point of time.
> 
> I think this has turned out to be sage advice from Martin, as I believe neither of us has received a reply from the Oracle copyright advisor. In the interests of completing this change, I would be happy to move forward with either of the following.
> 
> 1. The suggestion from IBM legal department to add both Oracle, and IBM copyright lines (with IBM lines only added to files with significant modification, as discussed above).
> 2. Reverting copyright header modifications other than year updates.
> 
> What are you most comfortable with, my sterling team of reviewers?

Hi Tyler, I'm fine with either.

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From shade at openjdk.java.net  Mon Feb 14 07:57:10 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 14 Feb 2022 07:57:10 GMT
Subject: RFR: 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails
 after JDK-8279997
In-Reply-To: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
References: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
Message-ID: <1-ihOr1hbdf01dEoYuzBP_hHto5gigkU-M5tz7imP-g=.73998529-7d9e-4b57-9038-0458342473c5@github.com>

On Mon, 14 Feb 2022 07:38:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change - the two new test cases added in JDK-8279997 do not work when the tests are executed with `jtreg -vmoptions:-Xshare:off`. This patch disable the two test cases under such condition to avoid causing CI failures
> 
> A proper fix will be done in https://bugs.openjdk.java.net/browse/JDK-8281715

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7457

From amenkov at openjdk.java.net  Mon Feb 14 09:22:17 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 14 Feb 2022 09:22:17 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v2]
In-Reply-To: <Hsb0o5RPH5NGRPsCvyIjj4YjG5PK_MfEKWYKxr38T1A=.2293c93b-9259-4de2-86aa-45d2afe3e5fb@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <OWv3zarvAM6dR6eEiX9DNAYWvhndoNShmeJb39V6ViE=.7377d5c4-49fa-493d-9647-8ec58617ed94@github.com>
 <bcTUnV_skmEldP11-Z6JstxG7PlYFtRnp3nPEyQozl8=.93572836-aa04-4250-8dfd-04d7e362d290@github.com>
 <Hsb0o5RPH5NGRPsCvyIjj4YjG5PK_MfEKWYKxr38T1A=.2293c93b-9259-4de2-86aa-45d2afe3e5fb@github.com>
Message-ID: <fXGdKjqS_GDb5gjHba21VqY5aGPdUGpx_7zqWyGroCQ=.734e0b71-adad-4a88-906c-c21cf3ef3974@github.com>

On Mon, 14 Feb 2022 05:02:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> HPROF_GC_CLASS_DUMP records contain references to signers and protection domain objects.
>> But this is properties of InstanceKlass, for array classes the properties from their element classes are written (or NULL for arrays of primitive types).
>> do_class_dump callback skips array classes:
>>   if (k->is_instance_klass()) {
>>     DumperSupport::dump_class_and_array_classes(writer(), k);
>>   }
>> 
>> dump_class_and_array_classes dumps the class and then iterate over array classes (k->array_klass_or_null()) and writes records for them (using signer and protection domain from the instance class specified).
>> 
>> This approach also skips primitive type arrays (they don't have corresponding InstanceKlass) - they are dumped separately.
>> 
>> I added the comment to explain why do_class_dump goes this tricky way.
>> Do you have any suggestions how to rephrase it to make clearer?
>
> Sorry about the delay. I didn't see your response when it came in.
> 
> It seems like this comment belongs with do_class_dump(). Putting it here is kind of confusing. Also, what is meant by "bottom class"? Do you mean the element type of the array?

This comment explains why we call ClassLoaderDataGraph::classes_do(do_class_dump) and then Universe::basic_type_classes_do(&do_basic_type_array_class_dump).

Bottom klass is 1-dimensional type.
For example for [[LObject; element type is [lObject;, and bottom klass is LObject;
Looked at the code and see that ObjAyyaKlass actually contains link to it - see ObjArrayKlass::bottom_klass(), so I can update do_class_dump to use it.

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From stuefe at openjdk.java.net  Mon Feb 14 09:37:09 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 09:37:09 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v3]
In-Reply-To: <qY2rvEcJxZOm6SEVdz0bQW9OVhAz2J8VS7M12Nfada0=.ebe6f12f-6c93-4d83-8c92-6ff985792549@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <qY2rvEcJxZOm6SEVdz0bQW9OVhAz2J8VS7M12Nfada0=.ebe6f12f-6c93-4d83-8c92-6ff985792549@github.com>
Message-ID: <b_wInUDXuWJQChswMEjku5OnoKGEXvCqXlK0nFXLoH8=.92818d6d-89fb-4c98-a459-628c62c19b79@github.com>

On Wed, 9 Feb 2022 07:20:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> release_multi_mappings_vm is unfortunately racy.
>> 
>> The original intention of the test was to check that `os::release_memory()` works across multiple mappings allocated with multiple calls to `os::reserve_memory()`. This was broken for a long time on windows, since it relies on the implicit assumption that every platform uses mmap-ish APIs under the hood. But Windows virtual memory API (and SysV shmat, for that matter) does not work that way.
>> 
>> The release_multi_mappings_vm test 
>> - A reserves a number of mappings in 4M stripes adjacent to each other 
>> - B releases them with a single call to os::release_memory
>> - C re-allocates a range at the same address
>> 
>> Step (C) will fail if the os::release call in (B) failed to release the mapping. Which it sometimes did silently, so just checking the return code in (B) was not sufficient.
>> 
>> Unfortunately, it will also fail if someone concurrently mapped into the range between (B) and (C). It's rare, but it happens.
>> 
>> This is difficult to make completely airtight, but we could make it much more stable:
>> 1) instead of releasing all stripes, just release the n middle stripes (n>1) and leave first and last stripe reserved. Then, in (C), re-reserve the middle stripes. Tests the same (as long as we have multiple middle stripes) but drastically decreases the chance of some random allocation placing memory into the vacated address hole
>> 2) reduce the stripe size from today's 4M to something much smaller. Again, reduces the chance of stray mappings being placed into the hole since it will be smaller too.
>> 
>> The patch does just that.
>> It also adds a lengthy comment.
>> I also needed to place the NUMASwitcher line in front of the last os::release_memory. That is done just  to clean up everything before the tests ends, but now its a multi-mapping-release too (we now release front stripe, middle, and end stripe).
>> 
>> Tests:
>> - GHAs
>> - manually ran the test on x64 Linux
>> - SAP nightlies
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation of TEST_VM line

No takers? Need a second review.

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From ihse at openjdk.java.net  Mon Feb 14 10:35:19 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 14 Feb 2022 10:35:19 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
Message-ID: <OiTHp7Kc3A6wnomUUABPM3GFWn4iUanEm2-U42iiTa4=.5e42991c-aa4d-4034-9dde-7cb4d81d4d79@github.com>

On Fri, 4 Feb 2022 00:25:43 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into JDK-8203290
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

make/autoconf/jvm-features.m4 line 3:

> 1: #
> 2: # Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved.
> 3: # Copyright (c) 2022, IBM Corp.

I understand the discussion about copyright lines has plagued this PR, but this really looks odd: adding an IBM copyright line when just removing code. That does not make sense to me.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From vlivanov at openjdk.java.net  Mon Feb 14 12:01:13 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 14 Feb 2022 12:01:13 GMT
Subject: Integrated: 8256368: Avoid repeated upcalls into Java to re-resolve
 MH/VH linkers/invokers
In-Reply-To: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
References: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
Message-ID: <QvuSdTyf5HYXKMD5R9mwn6dHdC-Kmq4UMAT_7fyu4Ws=.3872feb0-270b-4643-9ce4-d23b11b9f6bc@github.com>

On Thu, 10 Feb 2022 16:57:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> It's another attempt to fix JDK-8256368 (previous one was #1453). 
> 
> @coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 
> 
> After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
> For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.
> 
> Original description:
> 
> Method linkage of invokehandle instructions involve an upcall into Java
> (MethodHandleNatives::linkMethod), but the result is not cached. Unless the
> upcall behaves idempotently (which is highly desirable, but not guaranteed),
> repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
> switching to a higher tier involves call site re-resolution in generated code,
> but re-resolution installs a fresh method which puts execution back into
> interpreter.
> 
> (Another prerequisite is no inlining through a invokehandle which doesn't
> normally happen in practice - relevant methods are marked w/ @ForceInline -
> except some testing modes, -Xcomp in particular.)
> 
> Proposed fix is to inspect ConstantPoolCache first. Previous resolution
> attempts from interpreter and C1 records their results there and it stabilises
> the execution.
> 
> Testing: hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: 534e5578
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/534e557874274255c55086b4f6128063cbd9cc58
Stats:     47 lines in 5 files changed: 22 ins; 12 del; 13 mod

8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers

Reviewed-by: dlong, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/7429

From duke at openjdk.java.net  Mon Feb 14 12:21:06 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 14 Feb 2022 12:21:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v4]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <2VBJSCFH2jOBQ0ONVfSS0g4Pe9Wz88SZUBO1D3X4xmQ=.0a59d953-9e71-4811-b013-86dd2fed4dc3@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma 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 JDK-8271195
 - 8271195: Review comments resolved.
 - 8271195: Review comments resolved.
 - 8271195: Resolving jcheck failure.
 - 8271195: Use largest available large page size smaller than LargePageSizeInBytes when available

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/fadcb5b9..813ce0e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=02-03

  Stats: 16078 lines in 454 files changed: 11917 ins; 2152 del; 2009 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From dholmes at openjdk.java.net  Mon Feb 14 13:01:11 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Feb 2022 13:01:11 GMT
Subject: RFR: 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails
 after JDK-8279997
In-Reply-To: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
References: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
Message-ID: <jpa1XG1vRjzMfUI2EmS6qIlKQ8GMAyCMJHMRBIeIxfo=.5ca43b03-2a20-4d7e-bf67-5ad9a385eb3b@github.com>

On Mon, 14 Feb 2022 07:38:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change - the two new test cases added in JDK-8279997 do not work when the tests are executed with `jtreg -vmoptions:-Xshare:off`. This patch disable the two test cases under such condition to avoid causing CI failures
> 
> A proper fix will be done in https://bugs.openjdk.java.net/browse/JDK-8281715

Sorry but can you explain why -Xshare:off causes these subtests to fail. Don't they launch their own JVM with the desired flags?

Thanks,
David

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

PR: https://git.openjdk.java.net/jdk/pull/7457

From stuefe at openjdk.java.net  Mon Feb 14 13:02:08 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 13:02:08 GMT
Subject: RFR: 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails
In-Reply-To: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
References: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
Message-ID: <Q2N_yUkHF_wViyWMV-MFMZS-OliUrfuq9u1ivi5seeA=.37c53596-2d95-4821-8c35-b7689f50d8f4@github.com>

On Wed, 9 Feb 2022 23:02:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A simple fix to the test failure by specifying the heap sizes for most of the test cases.
> Before the fix, if the MaxHeapSize is determined by the VM, the MaxHeapSize could become smaller
> than the MinHeapSize or the InitialHeapSize which causing the failure.
> 
> Testing: CI tiers 1 - 4.

Sorry for the slow response, I just saw this. I'll give this a spin in our CI. From the outside it looks good.

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

PR: https://git.openjdk.java.net/jdk/pull/7413

From amenkov at openjdk.java.net  Mon Feb 14 13:05:52 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 14 Feb 2022 13:05:52 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3]
In-Reply-To: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
Message-ID: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>

> ClassLoaderDataGraph::classes_do description says:
> // Walking classes through the ClassLoaderDataGraph include array classes.
> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)

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

  reworked do_class_dump

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7384/files
  - new: https://git.openjdk.java.net/jdk/pull/7384/files/604b4f88..173a8da8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=01-02

  Stats: 96 lines in 1 file changed: 11 ins; 58 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7384.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7384/head:pull/7384

PR: https://git.openjdk.java.net/jdk/pull/7384

From amenkov at openjdk.java.net  Mon Feb 14 13:11:10 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 14 Feb 2022 13:11:10 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3]
In-Reply-To: <fXGdKjqS_GDb5gjHba21VqY5aGPdUGpx_7zqWyGroCQ=.734e0b71-adad-4a88-906c-c21cf3ef3974@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <OWv3zarvAM6dR6eEiX9DNAYWvhndoNShmeJb39V6ViE=.7377d5c4-49fa-493d-9647-8ec58617ed94@github.com>
 <bcTUnV_skmEldP11-Z6JstxG7PlYFtRnp3nPEyQozl8=.93572836-aa04-4250-8dfd-04d7e362d290@github.com>
 <Hsb0o5RPH5NGRPsCvyIjj4YjG5PK_MfEKWYKxr38T1A=.2293c93b-9259-4de2-86aa-45d2afe3e5fb@github.com>
 <fXGdKjqS_GDb5gjHba21VqY5aGPdUGpx_7zqWyGroCQ=.734e0b71-adad-4a88-906c-c21cf3ef3974@github.com>
Message-ID: <pMMF2aZonPccoaxfqlMvekDzTJsPsNVI8TZOnI91ZHk=.ae1d16f1-b79a-4e5c-8ead-4f8bf532dc96@github.com>

On Mon, 14 Feb 2022 09:18:34 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Sorry about the delay. I didn't see your response when it came in.
>> 
>> It seems like this comment belongs with do_class_dump(). Putting it here is kind of confusing. Also, what is meant by "bottom class"? Do you mean the element type of the array?
>
> This comment explains why we call ClassLoaderDataGraph::classes_do(do_class_dump) and then Universe::basic_type_classes_do(&do_basic_type_array_class_dump).
> 
> Bottom klass is 1-dimensional type.
> For example for [[LObject; element type is [lObject;, and bottom klass is LObject;
> Looked at the code and see that ObjArrayKlass actually contains link to it - see ObjArrayKlass::bottom_klass(), so I can update do_class_dump to use it.

I updated the fix, fixed do_class_dump and removed this comment.
This also removes code duplication in dump_class_and_array_classes and dump_basic_type_array_class

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From sjohanss at openjdk.java.net  Mon Feb 14 13:33:10 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 14 Feb 2022 13:33:10 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v3]
In-Reply-To: <qY2rvEcJxZOm6SEVdz0bQW9OVhAz2J8VS7M12Nfada0=.ebe6f12f-6c93-4d83-8c92-6ff985792549@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <qY2rvEcJxZOm6SEVdz0bQW9OVhAz2J8VS7M12Nfada0=.ebe6f12f-6c93-4d83-8c92-6ff985792549@github.com>
Message-ID: <v6ElFcgcXkBXOh0wjmJFuPlprMcu3xFagcOORbNecJ4=.4ffa7004-2319-4fdc-8e17-c41c1f7b0b35@github.com>

On Wed, 9 Feb 2022 07:20:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> release_multi_mappings_vm is unfortunately racy.
>> 
>> The original intention of the test was to check that `os::release_memory()` works across multiple mappings allocated with multiple calls to `os::reserve_memory()`. This was broken for a long time on windows, since it relies on the implicit assumption that every platform uses mmap-ish APIs under the hood. But Windows virtual memory API (and SysV shmat, for that matter) does not work that way.
>> 
>> The release_multi_mappings_vm test 
>> - A reserves a number of mappings in 4M stripes adjacent to each other 
>> - B releases them with a single call to os::release_memory
>> - C re-allocates a range at the same address
>> 
>> Step (C) will fail if the os::release call in (B) failed to release the mapping. Which it sometimes did silently, so just checking the return code in (B) was not sufficient.
>> 
>> Unfortunately, it will also fail if someone concurrently mapped into the range between (B) and (C). It's rare, but it happens.
>> 
>> This is difficult to make completely airtight, but we could make it much more stable:
>> 1) instead of releasing all stripes, just release the n middle stripes (n>1) and leave first and last stripe reserved. Then, in (C), re-reserve the middle stripes. Tests the same (as long as we have multiple middle stripes) but drastically decreases the chance of some random allocation placing memory into the vacated address hole
>> 2) reduce the stripe size from today's 4M to something much smaller. Again, reduces the chance of stray mappings being placed into the hole since it will be smaller too.
>> 
>> The patch does just that.
>> It also adds a lengthy comment.
>> I also needed to place the NUMASwitcher line in front of the last os::release_memory. That is done just  to clean up everything before the tests ends, but now its a multi-mapping-release too (we now release front stripe, middle, and end stripe).
>> 
>> Tests:
>> - GHAs
>> - manually ran the test on x64 Linux
>> - SAP nightlies
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation of TEST_VM line

Looks good ?? 

Took the test for some repeated spins through our test-environment and all looks good.

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

Marked as reviewed by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7288

From duke at openjdk.java.net  Mon Feb 14 14:24:55 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 14 Feb 2022 14:24:55 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v5]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <u4TXNk0g6fyVVbV0NqaEaX6cjmvNu2Edmcyoyq3DyG0=.1cb3ca7e-8c67-4393-aa1f-f50bae2bd112@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: Resolved the review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/813ce0e3..4c1d088e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=03-04

  Stats: 77 lines in 4 files changed: 33 ins; 19 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From stuefe at openjdk.java.net  Mon Feb 14 14:36:10 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 14:36:10 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v5]
In-Reply-To: <u4TXNk0g6fyVVbV0NqaEaX6cjmvNu2Edmcyoyq3DyG0=.1cb3ca7e-8c67-4393-aa1f-f50bae2bd112@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <u4TXNk0g6fyVVbV0NqaEaX6cjmvNu2Edmcyoyq3DyG0=.1cb3ca7e-8c67-4393-aa1f-f50bae2bd112@github.com>
Message-ID: <bNjFiD3IGbkbbkqcY7lk199jxjX0MAeW9lO5c-A83Fg=.4b667caa-f63a-497b-b46e-336db97f02e8@github.com>

On Mon, 14 Feb 2022 14:24:55 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Resolved the review comments

Sorry all for dropping out of the discussion.

> 
> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
> > 
> > 
> > I would actually like the following behavior:
> > ```
> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
> > 
> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
> > I think this is close to what we do now.
> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
> > ```
> > * a single 1G page and 256 2m pages for the heap
> > ```
> 
> Currently this would round the heap up to 2G and use 2 1G pages, right?

Right.

> But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages.

Probably the latter, with a warning. I expect in general the admin to be able to allocate enough huge pages, so error handling is rare and can be simple. Just my opinion.

> There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.

I understand this, but I am confused too: I thought large page memory is never uncommitted because we cannot be sure it can be recommitted? When does G1 uncommit large paged heap?

> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
> 
> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
> 
> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).

Yes, I think getting rid of default large page makes sense. And instinctively I would say "configured" means we were, at startup, able to allocate at least one page of that size.

> 
> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?

I think the latter. If we have multiple large pages, but no concept of default, the caller needs to specify its wish size.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From coleenp at openjdk.java.net  Mon Feb 14 16:31:12 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 14 Feb 2022 16:31:12 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
Message-ID: <-eNoZwJIQTGAHPsGYlpgRkRXCa2Y_tvxYpJz9XixK_0=.430cea16-ee15-4685-91c9-f5f5b35077e5@github.com>

On Sat, 12 Feb 2022 22:07:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
> 
> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
> 
> Thanks to Vladimir I.  for finding exact root cause of problem.

This looks good to me. Thank you for finding and fixing this!

src/hotspot/share/runtime/jniHandles.cpp line 388:

> 386:     block = NULL;
> 387:   } else {
> 388:     DEBUG_ONLY(block->set_pop_frame_link(NULL));

Can this also be an assert that the pop_frame_link is null ?

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7453

From stuefe at openjdk.java.net  Mon Feb 14 16:45:12 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 16:45:12 GMT
Subject: RFR: JDK-8280940: gtest os.release_multi_mappings_vm is racy [v3]
In-Reply-To: <v6ElFcgcXkBXOh0wjmJFuPlprMcu3xFagcOORbNecJ4=.4ffa7004-2319-4fdc-8e17-c41c1f7b0b35@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
 <qY2rvEcJxZOm6SEVdz0bQW9OVhAz2J8VS7M12Nfada0=.ebe6f12f-6c93-4d83-8c92-6ff985792549@github.com>
 <v6ElFcgcXkBXOh0wjmJFuPlprMcu3xFagcOORbNecJ4=.4ffa7004-2319-4fdc-8e17-c41c1f7b0b35@github.com>
Message-ID: <0fIJiILHS1uzoVwjz1mhL1Z-WuWTQIa4tPEuNduHGpY=.00267d80-1545-4b19-96c0-9a17ecbf9693@github.com>

On Mon, 14 Feb 2022 13:30:24 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix indentation of TEST_VM line
>
> Looks good ?? 
> 
> Took the test for some repeated spins through our test-environment and all looks good.

Thanks @kstefanj @kimbarrett and @dcubed-ojdk!

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From stuefe at openjdk.java.net  Mon Feb 14 16:45:13 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 16:45:13 GMT
Subject: Integrated: JDK-8280940: gtest os.release_multi_mappings_vm is racy
In-Reply-To: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
References: <mjInyFI08TaAkY9fwIPzonP_S1qDDR-PhShEFYnBXYE=.b067604c-c97a-4a6e-a5aa-0163169091c3@github.com>
Message-ID: <IOr829RctB_D7Skuo-simRe0OtZFubBpkoYpYU5LelE=.f9355874-a7c4-4b9c-8367-aee7b29d132d@github.com>

On Mon, 31 Jan 2022 12:20:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> release_multi_mappings_vm is unfortunately racy.
> 
> The original intention of the test was to check that `os::release_memory()` works across multiple mappings allocated with multiple calls to `os::reserve_memory()`. This was broken for a long time on windows, since it relies on the implicit assumption that every platform uses mmap-ish APIs under the hood. But Windows virtual memory API (and SysV shmat, for that matter) does not work that way.
> 
> The release_multi_mappings_vm test 
> - A reserves a number of mappings in 4M stripes adjacent to each other 
> - B releases them with a single call to os::release_memory
> - C re-allocates a range at the same address
> 
> Step (C) will fail if the os::release call in (B) failed to release the mapping. Which it sometimes did silently, so just checking the return code in (B) was not sufficient.
> 
> Unfortunately, it will also fail if someone concurrently mapped into the range between (B) and (C). It's rare, but it happens.
> 
> This is difficult to make completely airtight, but we could make it much more stable:
> 1) instead of releasing all stripes, just release the n middle stripes (n>1) and leave first and last stripe reserved. Then, in (C), re-reserve the middle stripes. Tests the same (as long as we have multiple middle stripes) but drastically decreases the chance of some random allocation placing memory into the vacated address hole
> 2) reduce the stripe size from today's 4M to something much smaller. Again, reduces the chance of stray mappings being placed into the hole since it will be smaller too.
> 
> The patch does just that.
> It also adds a lengthy comment.
> I also needed to place the NUMASwitcher line in front of the last os::release_memory. That is done just  to clean up everything before the tests ends, but now its a multi-mapping-release too (we now release front stripe, middle, and end stripe).
> 
> Tests:
> - GHAs
> - manually ran the test on x64 Linux
> - SAP nightlies

This pull request has now been integrated.

Changeset: f07b8165
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f07b8165231799383303e5c0755d07afd2feb7fd
Stats:     36 lines in 1 file changed: 24 ins; 1 del; 11 mod

8280940: gtest os.release_multi_mappings_vm is racy

Reviewed-by: dcubed, sjohanss

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

PR: https://git.openjdk.java.net/jdk/pull/7288

From lmesnik at openjdk.java.net  Mon Feb 14 16:57:12 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 14 Feb 2022 16:57:12 GMT
Subject: RFR: 8279949: JavaThread::_free_handle_block leaks native memory
In-Reply-To: <-eNoZwJIQTGAHPsGYlpgRkRXCa2Y_tvxYpJz9XixK_0=.430cea16-ee15-4685-91c9-f5f5b35077e5@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
 <-eNoZwJIQTGAHPsGYlpgRkRXCa2Y_tvxYpJz9XixK_0=.430cea16-ee15-4685-91c9-f5f5b35077e5@github.com>
Message-ID: <iq70lFLIrFIxU2iKBYSIgH-PknHpZPf-jPVyrNXSt-w=.1bd46646-585c-47c1-ba39-0c85920f5f43@github.com>

On Mon, 14 Feb 2022 16:27:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
>> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
>> 
>> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
>> 
>> Thanks to Vladimir I.  for finding exact root cause of problem.
>
> src/hotspot/share/runtime/jniHandles.cpp line 388:
> 
>> 386:     block = NULL;
>> 387:   } else {
>> 388:     DEBUG_ONLY(block->set_pop_frame_link(NULL));
> 
> Can this also be an assert that the pop_frame_link is null ?

This is a first block which can have non-NULL set_pop_frame_link. So I set it to NULL so assert in the while loop doesn't fail.

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From stuefe at openjdk.java.net  Mon Feb 14 17:14:19 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 17:14:19 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <OiTHp7Kc3A6wnomUUABPM3GFWn4iUanEm2-U42iiTa4=.5e42991c-aa4d-4034-9dde-7cb4d81d4d79@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <OiTHp7Kc3A6wnomUUABPM3GFWn4iUanEm2-U42iiTa4=.5e42991c-aa4d-4034-9dde-7cb4d81d4d79@github.com>
Message-ID: <ks-myorQ2juvYDwyy55_GmpQgTLnvy1Pj2TBxzuH2-I=.28ccb775-8873-4e70-8611-e65907ef47d2@github.com>

On Mon, 14 Feb 2022 10:32:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Merge branch 'master' into JDK-8203290
>>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>>  - Addresses issues from review and other sm fixes
>>    
>>    - Adds commenting in regards to memory handling by SystemProcess &
>>    NetworkInterface classes
>>    - Replaces explicit initialization and copy of structs with memcpy
>>    and memset as appropriate
>>    - Renames internal struct definitions in os_perf_aix
>>    - Other minor fixes
>>  - Changes macoss -> macosx in problem list
>>  - Refactors loadlib_aix: Removes redundant c++ class
>>  - Merge branch 'master' into JDK-8203290
>>  - Implements JFR on AIX
>>    
>>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>>    by TestNativeLibraies.java)
>>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>>    all platforms)
>>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux
>
> make/autoconf/jvm-features.m4 line 3:
> 
>> 1: #
>> 2: # Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved.
>> 3: # Copyright (c) 2022, IBM Corp.
> 
> I understand the discussion about copyright lines has plagued this PR, but this really looks odd: adding an IBM copyright line when just removing code. That does not make sense to me.

+1 Removing code does not add anything copyrightable; I'd remove that copyright line.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From iklam at openjdk.java.net  Mon Feb 14 17:23:09 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 14 Feb 2022 17:23:09 GMT
Subject: RFR: 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails
 after JDK-8279997
In-Reply-To: <jpa1XG1vRjzMfUI2EmS6qIlKQ8GMAyCMJHMRBIeIxfo=.5ca43b03-2a20-4d7e-bf67-5ad9a385eb3b@github.com>
References: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
 <jpa1XG1vRjzMfUI2EmS6qIlKQ8GMAyCMJHMRBIeIxfo=.5ca43b03-2a20-4d7e-bf67-5ad9a385eb3b@github.com>
Message-ID: <EGfoqgrDYesXuqBKQ8q4ZtIfIrnOfqFL7bhbqTPN3uw=.c31e64df-bd0c-4726-90ce-09b089873bf5@github.com>

On Mon, 14 Feb 2022 12:57:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but can you explain why -Xshare:off causes these subtests to fail. Don't they launch their own JVM with the desired flags?

The test case deletes `baseArchiveName` and then try to use the `-XX:+AutoCreateSharedArchive` flag, etc, to trigger a dynamic dump, which usually will fail (because the base archive doesn't exist) and print out the expected warning.

However, when `-vmoption:-Xshare:off` is specified, `isUseSharedSpacesDisabled()` returns true, and the `run`  method will internally recreated a base archive. This behavior is intended to make all the tests in the `dynamicArchive/` subdirectory work even if `-Xshare:off` is specified, but this would cause the two newly added test cases to fail.

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

PR: https://git.openjdk.java.net/jdk/pull/7457

From dcubed at openjdk.java.net  Mon Feb 14 17:52:09 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 14 Feb 2022 17:52:09 GMT
Subject: RFR: 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails
 after JDK-8279997
In-Reply-To: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
References: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
Message-ID: <uus3QpKV77hRTBfzP18-NuRNqEopjV0r8magsepU52Q=.1620dc3c-cb84-45ea-bcf3-c9e7020c1a82@github.com>

On Mon, 14 Feb 2022 07:38:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change - the two new test cases added in JDK-8279997 do not work when the tests are executed with `jtreg -vmoptions:-Xshare:off`. This patch disable the two test cases under such condition to avoid causing CI failures
> 
> A proper fix will be done in https://bugs.openjdk.java.net/browse/JDK-8281715

Thumbs up. Thanks for taking care of these Tier5 failures.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7457

From iklam at openjdk.java.net  Mon Feb 14 18:58:11 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 14 Feb 2022 18:58:11 GMT
Subject: RFR: 8281678: appcds/dynamicArchive/ArchiveConsistency.java fails
 after JDK-8279997
In-Reply-To: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
References: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
Message-ID: <IY9cvBUMtcMUuERe-IWF8tmbaBebg_J3ft5I_b8vbGM=.5d4c380f-59b2-4ace-b864-ce4cfff4425a@github.com>

On Mon, 14 Feb 2022 07:38:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change - the two new test cases added in JDK-8279997 do not work when the tests are executed with `jtreg -vmoptions:-Xshare:off`. This patch disable the two test cases under such condition to avoid causing CI failures
> 
> A proper fix will be done in https://bugs.openjdk.java.net/browse/JDK-8281715

I ran tiers 1,2,5 in our CI and no issues found.
Thanks @shipilev and @dcubed-ojdk for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/7457

From iklam at openjdk.java.net  Mon Feb 14 18:58:11 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 14 Feb 2022 18:58:11 GMT
Subject: Integrated: 8281678: appcds/dynamicArchive/ArchiveConsistency.java
 fails after JDK-8279997
In-Reply-To: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
References: <pekFWcbTz4rxXokKtE-bKlRjK3Z1YZI3m-ZON736KIs=.f062cce4-1234-4999-aa24-2f0e93699790@github.com>
Message-ID: <HXFYxNcBL_7d798nu9PKi6ghovMkaTuJuz7h57IOEXo=.2cefe96d-3cf5-4747-b3d0-35bd4aaad225@github.com>

On Mon, 14 Feb 2022 07:38:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial change - the two new test cases added in JDK-8279997 do not work when the tests are executed with `jtreg -vmoptions:-Xshare:off`. This patch disable the two test cases under such condition to avoid causing CI failures
> 
> A proper fix will be done in https://bugs.openjdk.java.net/browse/JDK-8281715

This pull request has now been integrated.

Changeset: 16f649b9
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/16f649b9c5b480d2a8499b1a92939cdf53ecc8dc
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8281678: appcds/dynamicArchive/ArchiveConsistency.java fails after JDK-8279997

Reviewed-by: shade, dcubed

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

PR: https://git.openjdk.java.net/jdk/pull/7457

From duke at openjdk.java.net  Mon Feb 14 23:44:40 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 14 Feb 2022 23:44:40 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
 - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
 - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
 - Addresses issues from review and other sm fixes
   
   - Adds commenting in regards to memory handling by SystemProcess &
   NetworkInterface classes
   - Replaces explicit initialization and copy of structs with memcpy
   and memset as appropriate
   - Renames internal struct definitions in os_perf_aix
   - Other minor fixes
 - Changes macoss -> macosx in problem list
 - Refactors loadlib_aix: Removes redundant c++ class
 - Merge branch 'master' into JDK-8203290
 - Implements JFR on AIX
   
   - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
   - Updates libperfstat_aix to contain functionality needed by os_perf_aix
   - Implements missing functionality in loadlib_aix (Fixes failure noted
   by TestNativeLibraies.java)
   - Removes platform checks for --enable-feature-jfr (Now enable-able on
   all platforms)
   - Enables TestNetworkUtilizationEvent.java which now passes on AIX
   - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

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

Changes: https://git.openjdk.java.net/jdk/pull/6885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6885&range=20
  Stats: 1231 lines in 10 files changed: 461 ins; 502 del; 268 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6885/head:pull/6885

PR: https://git.openjdk.java.net/jdk/pull/6885

From duke at openjdk.java.net  Mon Feb 14 23:44:42 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 14 Feb 2022 23:44:42 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v20]
In-Reply-To: <ks-myorQ2juvYDwyy55_GmpQgTLnvy1Pj2TBxzuH2-I=.28ccb775-8873-4e70-8611-e65907ef47d2@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <T80nQN1yaGdPmCaDpJGOuV0BgDdB61qCnxLtyhqrUOs=.cd095b29-74f0-4a91-b4c2-9a0e32f76559@github.com>
 <OiTHp7Kc3A6wnomUUABPM3GFWn4iUanEm2-U42iiTa4=.5e42991c-aa4d-4034-9dde-7cb4d81d4d79@github.com>
 <ks-myorQ2juvYDwyy55_GmpQgTLnvy1Pj2TBxzuH2-I=.28ccb775-8873-4e70-8611-e65907ef47d2@github.com>
Message-ID: <RM6SIE5T6lEONegknvxi96xGph4oEvIpNTYCuoWQwBo=.0f721b69-9b9a-49a9-aa43-87cbf27b68cb@github.com>

On Mon, 14 Feb 2022 17:11:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> make/autoconf/jvm-features.m4 line 3:
>> 
>>> 1: #
>>> 2: # Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved.
>>> 3: # Copyright (c) 2022, IBM Corp.
>> 
>> I understand the discussion about copyright lines has plagued this PR, but this really looks odd: adding an IBM copyright line when just removing code. That does not make sense to me.
>
> +1 Removing code does not add anything copyrightable; I'd remove that copyright line.

I agree. I no longer add the IBM copyright for files where a one line change, or only removals took place.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From duke at openjdk.java.net  Mon Feb 14 23:48:11 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 14 Feb 2022 23:48:11 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
Message-ID: <6XT1pHUBTLmQUGXs9LyRSNghnued-YvUQITnXgY3Lr8=.08bd4674-572f-4e9f-94bd-72d863f0fb2c@github.com>

On Mon, 14 Feb 2022 23:44:40 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Updated to remove IBM from the copyright header when only a small change to the file took place. I am ready to integrate, but I will leave it open for a day or so to allow for any more comments.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From cjplummer at openjdk.java.net  Tue Feb 15 06:14:12 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 15 Feb 2022 06:14:12 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3]
In-Reply-To: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>
Message-ID: <VeKq7OqjIMov-JxQre694AfP0hfL0lItABecZqTMVz0=.68447040-555f-40b8-8f4d-4fbfc59ea959@github.com>

On Mon, 14 Feb 2022 13:05:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> ClassLoaderDataGraph::classes_do description says:
>> // Walking classes through the ClassLoaderDataGraph include array classes.
>> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked do_class_dump

The changes look good. Have you verified that after your most recent changes you get the same sized hprof file as with your initial changes?

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

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7384

From lmesnik at openjdk.java.net  Tue Feb 15 06:50:24 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 15 Feb 2022 06:50:24 GMT
Subject: RFR: 8281771: Crash in java_lang_invoke_MethodType::print_signature
Message-ID: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>

The crash happens in java.lang.invoke.MethodType.<init> when VM tries to print this objec while rtype and ptypes are not initialized yet. So the fix is just to check if they are not NULL.

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

Commit messages:
 - 8281771: Crash in java_lang_invoke_MethodType::print_signature

Changes: https://git.openjdk.java.net/jdk/pull/7470/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7470&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281771
  Stats: 13 lines in 1 file changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7470.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7470/head:pull/7470

PR: https://git.openjdk.java.net/jdk/pull/7470

From dholmes at openjdk.java.net  Tue Feb 15 07:06:08 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Feb 2022 07:06:08 GMT
Subject: RFR: 8281771: Crash in
 java_lang_invoke_MethodType::print_signature
In-Reply-To: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
References: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
Message-ID: <DVjCF9YT-NqZsoxSGpCkbjcstw8yZLWovxFltac-BFs=.8d747cb8-c46a-4105-a192-e9a8485abac7@github.com>

On Tue, 15 Feb 2022 06:43:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The crash happens in java.lang.invoke.MethodType.<init> when VM tries to print this objec while rtype and ptypes are not initialized yet. So the fix is just to check if they are not NULL.

Hi Leonid,

Looks good.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7470

From shade at openjdk.java.net  Tue Feb 15 07:14:12 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 07:14:12 GMT
Subject: RFR: 8281771: Crash in
 java_lang_invoke_MethodType::print_signature
In-Reply-To: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
References: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
Message-ID: <Dt7QMNE0TtAIQpL4q32aY_y5GtBkWDF8eT-m-PPVE94=.67d1f1f5-b568-4e0b-8435-a08606bf77df@github.com>

On Tue, 15 Feb 2022 06:43:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The crash happens in java.lang.invoke.MethodType.<init> when VM tries to print this objec while rtype and ptypes are not initialized yet. So the fix is just to check if they are not NULL.

Missed the spot?

src/hotspot/share/classfile/javaClasses.cpp line 4100:

> 4098:   oop rt = rtype(mt);
> 4099:   if (rt != NULL) {
> 4100:     java_lang_Class::print_signature(rtype(mt), st);

Suggestion:

    java_lang_Class::print_signature(rt, st);

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

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7470

From shade at openjdk.java.net  Tue Feb 15 07:24:54 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 07:24:54 GMT
Subject: RFR: 8281771: Crash in
 java_lang_invoke_MethodType::print_signature [v2]
In-Reply-To: <KXmOfDFUQIf10_tJx_aJSOJDRkTMtrPtbXN_3r7w1do=.93e82df1-f213-459d-9a99-2cb81eb3a424@github.com>
References: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
 <KXmOfDFUQIf10_tJx_aJSOJDRkTMtrPtbXN_3r7w1do=.93e82df1-f213-459d-9a99-2cb81eb3a424@github.com>
Message-ID: <wHphgYMTm56H1QjpaLsuEXrkRTtuZWd1muSm0YAeP3Q=.f2af85e9-5d92-410f-9984-e6606652d38c@github.com>

On Tue, 15 Feb 2022 07:21:53 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The crash happens in java.lang.invoke.MethodType.<init> when VM tries to print this objec while rtype and ptypes are not initialized yet. So the fix is just to check if they are not NULL.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/classfile/javaClasses.cpp
>   
>   Co-authored-by: Aleksey Shipil?v <shade at redhat.com>

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7470

From lmesnik at openjdk.java.net  Tue Feb 15 07:24:55 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 15 Feb 2022 07:24:55 GMT
Subject: RFR: 8281771: Crash in
 java_lang_invoke_MethodType::print_signature [v2]
In-Reply-To: <Dt7QMNE0TtAIQpL4q32aY_y5GtBkWDF8eT-m-PPVE94=.67d1f1f5-b568-4e0b-8435-a08606bf77df@github.com>
References: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
 <Dt7QMNE0TtAIQpL4q32aY_y5GtBkWDF8eT-m-PPVE94=.67d1f1f5-b568-4e0b-8435-a08606bf77df@github.com>
Message-ID: <q7NXc3jEd0CCnpoZZOTyqoFWYq1eETMxRB0eT6no_gc=.dc041106-677d-449c-819d-54ecc3526645@github.com>

On Tue, 15 Feb 2022 07:10:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/classfile/javaClasses.cpp
>>   
>>   Co-authored-by: Aleksey Shipil?v <shade at redhat.com>
>
> src/hotspot/share/classfile/javaClasses.cpp line 4100:
> 
>> 4098:   oop rt = rtype(mt);
>> 4099:   if (rt != NULL) {
>> 4100:     java_lang_Class::print_signature(rtype(mt), st);
> 
> Suggestion:
> 
>     java_lang_Class::print_signature(rt, st);

thanks

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

PR: https://git.openjdk.java.net/jdk/pull/7470

From lmesnik at openjdk.java.net  Tue Feb 15 07:24:53 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 15 Feb 2022 07:24:53 GMT
Subject: RFR: 8281771: Crash in
 java_lang_invoke_MethodType::print_signature [v2]
In-Reply-To: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
References: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
Message-ID: <KXmOfDFUQIf10_tJx_aJSOJDRkTMtrPtbXN_3r7w1do=.93e82df1-f213-459d-9a99-2cb81eb3a424@github.com>

> The crash happens in java.lang.invoke.MethodType.<init> when VM tries to print this objec while rtype and ptypes are not initialized yet. So the fix is just to check if they are not NULL.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/classfile/javaClasses.cpp
  
  Co-authored-by: Aleksey Shipil?v <shade at redhat.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7470/files
  - new: https://git.openjdk.java.net/jdk/pull/7470/files/c96f9a40..d4b812f8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7470&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7470&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7470

From stuefe at openjdk.java.net  Tue Feb 15 07:34:08 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 15 Feb 2022 07:34:08 GMT
Subject: RFR: 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails
In-Reply-To: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
References: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
Message-ID: <HZdqifS_h_Hlu4Y_6iODiuCVKVQPfHC6ls2omgh6Wvw=.86047007-c614-4e9e-a948-75b17d885e8e@github.com>

On Wed, 9 Feb 2022 23:02:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A simple fix to the test failure by specifying the heap sizes for most of the test cases.
> Before the fix, if the MaxHeapSize is determined by the VM, the MaxHeapSize could become smaller
> than the MinHeapSize or the InitialHeapSize which causing the failure.
> 
> Testing: CI tiers 1 - 4.

Tests ran through at SAP, patch looks good. Thank you for fixing this!

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7413

From dholmes at openjdk.java.net  Tue Feb 15 07:48:09 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Feb 2022 07:48:09 GMT
Subject: RFR: 8281771: Crash in
 java_lang_invoke_MethodType::print_signature [v2]
In-Reply-To: <KXmOfDFUQIf10_tJx_aJSOJDRkTMtrPtbXN_3r7w1do=.93e82df1-f213-459d-9a99-2cb81eb3a424@github.com>
References: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
 <KXmOfDFUQIf10_tJx_aJSOJDRkTMtrPtbXN_3r7w1do=.93e82df1-f213-459d-9a99-2cb81eb3a424@github.com>
Message-ID: <cKW5VLokdGHqtO2udCMgG0Ac1_jwlFH6T2seB6SSSwQ=.96cbe8a7-336b-49ce-a59d-ca38ee4f7a96@github.com>

On Tue, 15 Feb 2022 07:24:53 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The crash happens in java.lang.invoke.MethodType.<init> when VM tries to print this objec while rtype and ptypes are not initialized yet. So the fix is just to check if they are not NULL.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/classfile/javaClasses.cpp
>   
>   Co-authored-by: Aleksey Shipil?v <shade at redhat.com>

Good catch @shipilev !

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7470

From thartmann at openjdk.java.net  Tue Feb 15 09:42:14 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Feb 2022 09:42:14 GMT
Subject: RFR: 8281812: x86: Use short jumps in TemplateTable::condy_helper
In-Reply-To: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
References: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
Message-ID: <mdqhZHFaTt27-yE6Qokmj8pF0CfRw0cWGdW9GkwZMnY=.8e398e7b-2694-40b1-8f24-7ec6ce9c3db5@github.com>

On Tue, 15 Feb 2022 08:57:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8281744](https://bugs.openjdk.java.net/browse/JDK-8281744), this change improves TemplateTable::condy_helper, for the same reason: there are only a few pushes between the jumps, and we can tell MacroAssembler those can be short. There is no significant code that uses condy yet (I think), so the performance improvement for condy is only theoretical. This makes interpreter code a bit more compact, though.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`
>  - [x] Linux x86_32 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`

This should go to hotspot/runtime.

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

PR: https://git.openjdk.java.net/jdk/pull/7473

From stuefe at openjdk.java.net  Tue Feb 15 10:45:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 15 Feb 2022 10:45:15 GMT
Subject: RFR: 8280088: NMT: Make mtGCCardSet the subcategory of mtGC
In-Reply-To: <j-MaUDYtLcNaZy9LsgwAHwT87P5VwZSIoFB_YmcacZg=.4706f865-9b10-4e9f-8832-98b8e1a548bc@github.com>
References: <j-MaUDYtLcNaZy9LsgwAHwT87P5VwZSIoFB_YmcacZg=.4706f865-9b10-4e9f-8832-98b8e1a548bc@github.com>
Message-ID: <7ODt2SGnHlvpbfDtVNzPStP2e0KCmhnGENsXgQnrjXo=.067bf955-497c-4d90-a1f3-96714f4ccaa3@github.com>

On Mon, 17 Jan 2022 18:11:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163) introduced a new category, `mtGCCardSet` in NMT tracking. This makes logging look rather weird, and technically miscounts the space taken by GC-specific data structures, if you are accustomed to look at "GC" only:
> 
> 
> - GC (reserved=142426KB, committed=142426KB)
>                             (malloc=89554KB #3658)
>                             (mmap: reserved=52872KB, committed=52872KB)
>  
> - GCCardSet (reserved=128KB, committed=128KB)
>                             (malloc=128KB #1539)
> 
> 
> We can instead recast it as the subcategory of `mtGC`. It would be similar to `mtThreadStacks` that are accounted separately, but reported as part of `mtThread`.
> 
> 
> - GC (reserved=142584KB, committed=142584KB)
>                             (card sets: 128KB)
>                             (malloc=89583KB #3780)
>                             (mmap: reserved=52872KB, committed=52872KB) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `runtime/NMT`
>  - [ ] Linux x86_64 fastdebug `tier1`

I created https://bugs.openjdk.java.net/browse/JDK-8281819 to track the proposed NMT category grouping

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

PR: https://git.openjdk.java.net/jdk/pull/7115

From redestad at openjdk.java.net  Tue Feb 15 10:55:09 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 15 Feb 2022 10:55:09 GMT
Subject: RFR: 8281812: x86: Use short jumps in TemplateTable::condy_helper
In-Reply-To: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
References: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
Message-ID: <iRAsEwVZwQtdzl-ej9Ll2-ydqOr_Mk4TmW0Y8zEK2Os=.b919a772-413b-4234-9297-f8f89471a151@github.com>

On Tue, 15 Feb 2022 08:57:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8281744](https://bugs.openjdk.java.net/browse/JDK-8281744), this change improves TemplateTable::condy_helper, for the same reason: there are only a few pushes between the jumps, and we can tell MacroAssembler those can be short. There is no significant code that uses condy yet (I think), so the performance improvement for condy is only theoretical. This makes interpreter code a bit more compact, though.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`
>  - [x] Linux x86_32 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`

Looks good. I might even call it trivial, since the labels are all clearly bound just a few instructions away.

Out of curiousity, do you have data readily available on how much smaller a `jccb` becomes than a `jcc`, exactly?

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

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7473

From shade at openjdk.java.net  Tue Feb 15 11:03:10 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 11:03:10 GMT
Subject: RFR: 8281812: x86: Use short jumps in TemplateTable::condy_helper
In-Reply-To: <iRAsEwVZwQtdzl-ej9Ll2-ydqOr_Mk4TmW0Y8zEK2Os=.b919a772-413b-4234-9297-f8f89471a151@github.com>
References: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
 <iRAsEwVZwQtdzl-ej9Ll2-ydqOr_Mk4TmW0Y8zEK2Os=.b919a772-413b-4234-9297-f8f89471a151@github.com>
Message-ID: <16W0pyYLVGtrFpTfmkWu26rVT40uVJbrHRq-agJpAGw=.91928a17-5d45-45c5-8823-71b96801af40@github.com>

On Tue, 15 Feb 2022 10:51:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Out of curiousity, do you have data readily available on how much smaller a `jccb` becomes than a `jcc`, exactly?

`perfasm` says `jccb` takes 2 bytes, while `jcc` takes 6 bytes. It matches the `Assembler::jcc`: https://github.com/openjdk/jdk/blob/1c12b159ffcbb3528a20ac585d8460bf730e303d/src/hotspot/cpu/x86/assembler_x86.cpp#L2259-L2260

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

PR: https://git.openjdk.java.net/jdk/pull/7473

From ihse at openjdk.java.net  Tue Feb 15 11:11:16 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 11:11:16 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
Message-ID: <NMMk6oNwnihqatYzjjsHgo5ARuhV5rwYhpXOL6OlCdU=.d0b97f9a-e972-48a9-9b79-832618033d68@github.com>

On Mon, 14 Feb 2022 23:44:40 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Build changes now look good.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6885

From amenkov at openjdk.java.net  Tue Feb 15 11:59:06 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 15 Feb 2022 11:59:06 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3]
In-Reply-To: <VeKq7OqjIMov-JxQre694AfP0hfL0lItABecZqTMVz0=.68447040-555f-40b8-8f4d-4fbfc59ea959@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>
 <VeKq7OqjIMov-JxQre694AfP0hfL0lItABecZqTMVz0=.68447040-555f-40b8-8f4d-4fbfc59ea959@github.com>
Message-ID: <VwWWDieYB9oE7ZItj_GWYGijjP-O4dXHqdLn8IeWrbU=.693d3d7a-5446-4f58-a84c-7c3fae6a7b52@github.com>

On Tue, 15 Feb 2022 06:10:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The changes look good. Have you verified that after your most recent changes you get the same sized hprof file as with your initial changes?

Thank you for the review.
I verified number of classes (HPROF_LOAD_CLASS and HPROF_GC_CLASS_DUMP records) are the same with initial change and with the most recent (and the numbers of HPROF_GC_CLASS_DUMP records are the same as without the fix).
Size of the hprof file changes slightly from run to run (+-1KB for 2.5MB hprof file), so we can't rely on it

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From shade at openjdk.java.net  Tue Feb 15 12:00:40 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 12:00:40 GMT
Subject: RFR: 8281822: serviceability/7170638/SDTProbesGNULinuxTest.java test
 fails on !DTRACE_ENABLED builds after JDK-8278423
Message-ID: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>

This reproduces in GHA in x86_32 mode.

Reproduces locally too:


$ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java

java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout

at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)


The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant section in `libjvm.so`, so it fails. We should extend the checks to these new options too.

Additional testing:
 - [ ] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
 - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From shade at openjdk.java.net  Tue Feb 15 12:01:07 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 12:01:07 GMT
Subject: RFR: 8281812: x86: Use short jumps in TemplateTable::condy_helper
In-Reply-To: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
References: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
Message-ID: <Nv-LEmQiP7a34_1Upnnzxt3ffzAs5vSXf0-o5XfbRz4=.b2a39cbe-413e-4fb1-a212-3f89760a95f4@github.com>

On Tue, 15 Feb 2022 08:57:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8281744](https://bugs.openjdk.java.net/browse/JDK-8281744), this change improves TemplateTable::condy_helper, for the same reason: there are only a few pushes between the jumps, and we can tell MacroAssembler those can be short. There is no significant code that uses condy yet (I think), so the performance improvement for condy is only theoretical. This makes interpreter code a bit more compact, though.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`
>  - [x] Linux x86_32 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`

The GHA failure on x86_32 is new and unrelated: https://bugs.openjdk.java.net/browse/JDK-8281822

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

PR: https://git.openjdk.java.net/jdk/pull/7473

From dholmes at openjdk.java.net  Tue Feb 15 12:13:09 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Feb 2022 12:13:09 GMT
Subject: RFR: 8281822: serviceability/7170638/SDTProbesGNULinuxTest.java
 test fails on !DTRACE_ENABLED builds after JDK-8278423
In-Reply-To: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
Message-ID: <Tyc6DgcuQCQZX2V0FXfqGRBuGOurnLcAxdV5FuvAx0U=.5d79314d-2f62-4ad0-8435-fc46cebb1811@github.com>

On Tue, 15 Feb 2022 11:54:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This reproduces in GHA in x86_32 mode.
> 
> Reproduces locally too:
> 
> 
> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
> 
> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
> 
> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> 
> 
> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes

Looks good!

So JDK-8278423 exposed this pre-existing bug.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7477

From sjohanss at openjdk.java.net  Tue Feb 15 12:14:10 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 15 Feb 2022 12:14:10 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v5]
In-Reply-To: <bNjFiD3IGbkbbkqcY7lk199jxjX0MAeW9lO5c-A83Fg=.4b667caa-f63a-497b-b46e-336db97f02e8@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <u4TXNk0g6fyVVbV0NqaEaX6cjmvNu2Edmcyoyq3DyG0=.1cb3ca7e-8c67-4393-aa1f-f50bae2bd112@github.com>
 <bNjFiD3IGbkbbkqcY7lk199jxjX0MAeW9lO5c-A83Fg=.4b667caa-f63a-497b-b46e-336db97f02e8@github.com>
Message-ID: <pZjeAhkN6g1ci9_3d6N_Vv51Vn8_Mxh_FpVyHKQoGPs=.97fc94df-16e2-4265-9ea9-2aaa79b5706b@github.com>

On Mon, 14 Feb 2022 14:33:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages.
> 
> Probably the latter, with a warning. I expect in general the admin to be able to allocate enough huge pages, so error handling is rare and can be simple. Just my opinion.

Yes, deciding how much to help vs how much to expect from the configuration is not crystal clear. I know we have also discussed that one can query how many pages are in the pool and do decisions from that as well, but I think that might be over the top. 


> > There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
> 
> I understand this, but I am confused too: I thought large page memory is never uncommitted because we cannot be sure it can be recommitted? When does G1 uncommit large paged heap?
> 
As you say we can't uncommit when large pages are used, but we keep track that the range of pages are dirty and need clearing if reused later. (Might be room for some concurrent clearing here)

> > This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
> > If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
> 
> Yes, I think getting rid of default large page makes sense. And instinctively I would say "configured" means we were, at startup, able to allocate at least one page of that size.
> 
I think this would be a good way forward, to just allow use of page sizes which pass the sanity check. But I still think there might be a usecase for `LargePageSizeInBytes`, if you want to restrict the maximum used page size for the JVM. Say for example that your 1G-pool is for someother application.

> > Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
> 
> I think the latter. If we have multiple large pages, but no concept of default, the caller needs to specify its wish size.

So do I, I'll file some enhancements.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From shade at openjdk.java.net  Tue Feb 15 12:18:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 12:18:06 GMT
Subject: RFR: 8281822: serviceability/7170638/SDTProbesGNULinuxTest.java
 test fails on !DTRACE_ENABLED builds after JDK-8278423
In-Reply-To: <Tyc6DgcuQCQZX2V0FXfqGRBuGOurnLcAxdV5FuvAx0U=.5d79314d-2f62-4ad0-8435-fc46cebb1811@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <Tyc6DgcuQCQZX2V0FXfqGRBuGOurnLcAxdV5FuvAx0U=.5d79314d-2f62-4ad0-8435-fc46cebb1811@github.com>
Message-ID: <rU5wnvnZqDz6MTlW33iX3TVPNSWr7LzN0Y3bxDoB4D4=.f863ea96-26da-4bcf-a04c-b637296ad1ef@github.com>

On Tue, 15 Feb 2022 12:10:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So JDK-8278423 exposed this pre-existing bug.

Yup!

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From shade at openjdk.java.net  Tue Feb 15 12:18:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 12:18:06 GMT
Subject: RFR: 8281822: serviceability/7170638/SDTProbesGNULinuxTest.java
 test fails on !DTRACE_ENABLED builds after JDK-8278423
In-Reply-To: <rU5wnvnZqDz6MTlW33iX3TVPNSWr7LzN0Y3bxDoB4D4=.f863ea96-26da-4bcf-a04c-b637296ad1ef@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <Tyc6DgcuQCQZX2V0FXfqGRBuGOurnLcAxdV5FuvAx0U=.5d79314d-2f62-4ad0-8435-fc46cebb1811@github.com>
 <rU5wnvnZqDz6MTlW33iX3TVPNSWr7LzN0Y3bxDoB4D4=.f863ea96-26da-4bcf-a04c-b637296ad1ef@github.com>
Message-ID: <ozJf-mkjBuNbVqbKDqSD5ZDgUxa-x_d8ZBTnjHvxOjc=.d6847580-2915-4524-807e-dbb18744a824@github.com>

On Tue, 15 Feb 2022 12:14:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > So JDK-8278423 exposed this pre-existing bug.
> 
> Yup!

Come to think about it, I can rename this bug to something more generic and backport it, so that older VMs barf on trying to enable DTrace where not available.

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From stuefe at openjdk.java.net  Tue Feb 15 13:22:14 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 15 Feb 2022 13:22:14 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
Message-ID: <65raOl-IqN_v_gVtB314q1tigH6pl_pCCbF3MmIEjqQ=.4ee6fbcd-39cc-4dc6-a3ec-9e56e765298c@github.com>

On Mon, 14 Feb 2022 23:44:40 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Looks still good to me.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From jiefu at openjdk.java.net  Tue Feb 15 14:59:30 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 15 Feb 2022 14:59:30 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467
Message-ID: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>

Hi all,

runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.

This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.

 824   address generate_fp_mask(const char *stub_name, int64_t mask) {
 825     __ align(CodeEntryAlignment);
 826     StubCodeMark mark(this, "StubRoutines", stub_name);
 827     address start = __ pc();
 828
 829     __ emit_data64( mask, relocInfo::none );
 830     __ emit_data64( mask, relocInfo::none );
 831
 832     return start;
 833   }


Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.

1184 void MacroAssembler::align(int modulus) {
1185   // 8273459: Ensure alignment is possible with current segment alignment
1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
1187   align(modulus, offset());
1188 }
1189
1190 void MacroAssembler::align(int modulus, int target) {
1191   if (target % modulus != 0) {
1192     nop(modulus - (target % modulus));
1193   }
1194 }


The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.

This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8281829: runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after JDK-8281467

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

PR: https://git.openjdk.java.net/jdk/pull/7480

From shade at openjdk.java.net  Tue Feb 15 15:20:13 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 15:20:13 GMT
Subject: RFR: 8281822: serviceability/7170638/SDTProbesGNULinuxTest.java
 test fails on !DTRACE_ENABLED builds after JDK-8278423
In-Reply-To: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
Message-ID: <LlsM3Rz4WqR4SvCmRoo1S1lFnqIMmUgKu1ROaRMdlWo=.ed75c5df-5706-444a-b0bb-c4e1eced6503@github.com>

On Tue, 15 Feb 2022 11:54:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This reproduces in GHA in x86_32 mode.
> 
> Reproduces locally too:
> 
> 
> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
> 
> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
> 
> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> 
> 
> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes

All right, there are legitimate GHA test failures now in `compiler/runtime/Test8168712.java`, which enables `-XX:+DTraceMethodProbes`. I'll fix that too...

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From shade at openjdk.java.net  Tue Feb 15 16:11:48 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 16:11:48 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v2]
In-Reply-To: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
Message-ID: <r5j1bYGT03KgJ-wZ-_U9nQiEjbgdpfaUZwo19HLHdtI=.7e592562-e7c0-49c2-985c-49db6ceea613@github.com>

> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
> 
> 
> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
> 
> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
> 
> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> 
> 
> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
> 
> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Explicit DTraceOptionsTest
 - Sense DTrace build option

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7477/files
  - new: https://git.openjdk.java.net/jdk/pull/7477/files/29ce59a9..b799af8c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7477&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7477&range=00-01

  Stats: 114 lines in 7 files changed: 100 ins; 13 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7477.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7477/head:pull/7477

PR: https://git.openjdk.java.net/jdk/pull/7477

From shade at openjdk.java.net  Tue Feb 15 16:11:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 16:11:49 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v2]
In-Reply-To: <Tyc6DgcuQCQZX2V0FXfqGRBuGOurnLcAxdV5FuvAx0U=.5d79314d-2f62-4ad0-8435-fc46cebb1811@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <Tyc6DgcuQCQZX2V0FXfqGRBuGOurnLcAxdV5FuvAx0U=.5d79314d-2f62-4ad0-8435-fc46cebb1811@github.com>
Message-ID: <sJ7QOOJAfEzvvW0yEhOrPx7rVXPposfJa3Yq5WmDcWo=.6a15b807-5d16-4f3c-aae6-74091a6e7454@github.com>

On Tue, 15 Feb 2022 12:10:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Explicit DTraceOptionsTest
>>  - Sense DTrace build option
>
> Looks good!
> 
> So JDK-8278423 exposed this pre-existing bug.
> 
> Thanks,
> David

...and done. @dholmes-ora, you might want to take a look again, as went much farther than the initial PR.

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From sjohanss at openjdk.java.net  Tue Feb 15 16:20:14 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 15 Feb 2022 16:20:14 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
 <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
 <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>
 <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>
 <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@github.com>
 <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@github.com>
Message-ID: <1Uayyf2VJQfX2hHgivhQGdjTs0MV8iczBz-WPlOxCmU=.d59f7982-6ad5-4715-898e-0222e3581b83@github.com>

On Thu, 10 Feb 2022 10:09:24 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>>> > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>>> 
>>> I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>>> 
>> Thanks for digging out the JBS issue for this.
>> 
>>> > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>>> 
>>> I would actually like the following behavior:
>>> 
>>>     * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>>> 
>>>     * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>>> 
>>> 
>>> I think this is close to what we do now.
>>> 
>>> So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>>> 
>>>     * a single 1G page and 256 2m pages for the heap
>>> 
>> 
>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated. 
>> 
>>>     * 128 2m pages for the code cache
>>>       ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>>> 
>>> 
>>> Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>> 
>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>> 
>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes). 
>> 
>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
>
>> > > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>> > 
>> > 
>> > I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>> 
>> Thanks for digging out the JBS issue for this.
>> 
>> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>> > 
>> > 
>> > I would actually like the following behavior:
>> > ```
>> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>> > 
>> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > I think this is close to what we do now.
>> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>> > ```
>> > * a single 1G page and 256 2m pages for the heap
>> > ```
>> 
>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
>> 
>> > ```
>> > * 128 2m pages for the code cache
>> >   ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>> 
>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>> 
>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
>> 
>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
> 
> Hi @kstefanj , @tstuefe 
> 
> Thanks for sharing your views and comments. 
> Please suggest what specific change you want us to do in the patch since it is fixing the already existing functionality.
> 
> Best Regards,
> Swati

@swati-sha, I took a closer look at the test-case and right now it won't work when run on aarch64? On those systems in our test environment the base page size is 64k and the large page sizes are 2m and 512m. I took it for a spin to see what failures we would get and here it is:

[0.001s][info][pagesize] LargePageSizeInBytes is not a valid large page size (1G) using the default large page size: 512M
[0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
[0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
[0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
[0.002s][info   ][pagesize] CodeHeap 'non-nmethods':  min=2496K max=5760K base=0x0000fffec55d0000 page_size=64K size=5760K
[0.002s][info   ][pagesize] CodeHeap 'profiled nmethods':  min=2496K max=120000K base=0x0000fffec5b70000 page_size=64K size=120000K
[0.002s][info   ][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K max=120000K base=0x0000fffecd0a0000 page_size=64K size=120000K
[0.002s][info   ][pagesize] Heap:  min=1G max=2G base=0x0000000080000000 page_size=64K size=2G
[0.002s][info   ][pagesize] Card Table:  min=4194305B max=4194305B base=0x0000fffee0db0000 page_size=64K size=4160K
[0.003s][info   ][pagesize] Mark Bitmap:  min=64M max=64M base=0x0000fffebc000000 page_size=64K size=64M
[0.003s][info   ][pagesize] Parallel Compact Data:  min=160K max=160K base=0x0000fffee08b0000 page_size=64K size=192K
[0.003s][info   ][pagesize] Parallel Compact Data:  min=4M max=4M base=0x0000fffee04b0000 page_size=64K size=4M
System does not support 1G pages
Number of 2M pages = 0

System does not support 1G pages
Number of reserved 1G pages = -1

Number of reserved 2M pages = 0

TestCase1 skipped

TestCase2 skipped

Exceptionjava.lang.RuntimeException: System property 'test.jdk' not set. This property is normally set by jtreg. When running test separately, set this property using '-Dtest.jdk=/path/to/jdk'.
TestCase4 skipped

----------System.err:(11/560)----------
java.lang.AssertionError: Failed 4K page allocation

	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:81)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:828)


So either we need to make the test more robust to also work without having hard coded page sizes but rather figure them out during the "setup" stage or we need to add a requires to avoid running on aarch64. I would prefer if the test was fixed to get more coverage and testing with different page sizes. Doing the requires could look something like: 

@requires os.arch=="amd64" | os.arch=="x86_64"

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From neliasso at openjdk.java.net  Tue Feb 15 16:25:09 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 15 Feb 2022 16:25:09 GMT
Subject: RFR: 8281812: x86: Use short jumps in TemplateTable::condy_helper
In-Reply-To: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
References: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
Message-ID: <LXhaOe45QRxRdLFRfSBvbQZf7s2HfpXmdJ-l2uETf28=.86eab943-a7ca-4abb-9360-7199ffe6bab5@github.com>

On Tue, 15 Feb 2022 08:57:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8281744](https://bugs.openjdk.java.net/browse/JDK-8281744), this change improves TemplateTable::condy_helper, for the same reason: there are only a few pushes between the jumps, and we can tell MacroAssembler those can be short. There is no significant code that uses condy yet (I think), so the performance improvement for condy is only theoretical. This makes interpreter code a bit more compact, though.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`
>  - [x] Linux x86_32 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`

Looks good!

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

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7473

From kvn at openjdk.java.net  Tue Feb 15 16:33:09 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 15 Feb 2022 16:33:09 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467
In-Reply-To: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
Message-ID: <1Gt0BWpEFapG1PrGP08TdHo-cfINrj1bvEwBEZJIURk=.eff3dbf1-cb92-4465-9e49-b8fb0394b670@github.com>

On Tue, 15 Feb 2022 14:51:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
> It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.
> 
> This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.
> 
>  824   address generate_fp_mask(const char *stub_name, int64_t mask) {
>  825     __ align(CodeEntryAlignment);
>  826     StubCodeMark mark(this, "StubRoutines", stub_name);
>  827     address start = __ pc();
>  828
>  829     __ emit_data64( mask, relocInfo::none );
>  830     __ emit_data64( mask, relocInfo::none );
>  831
>  832     return start;
>  833   }
> 
> 
> Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.
> 
> 1184 void MacroAssembler::align(int modulus) {
> 1185   // 8273459: Ensure alignment is possible with current segment alignment
> 1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
> 1187   align(modulus, offset());
> 1188 }
> 1189
> 1190 void MacroAssembler::align(int modulus, int target) {
> 1191   if (target % modulus != 0) {
> 1192     nop(modulus - (target % modulus));
> 1193   }
> 1194 }
> 
> 
> The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.
> 
> This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
> And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.
> 
> Thanks.
> Best regards,
> Jie

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7480

From ccheung at openjdk.java.net  Tue Feb 15 17:22:08 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 15 Feb 2022 17:22:08 GMT
Subject: RFR: 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails
In-Reply-To: <HZdqifS_h_Hlu4Y_6iODiuCVKVQPfHC6ls2omgh6Wvw=.86047007-c614-4e9e-a948-75b17d885e8e@github.com>
References: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
 <HZdqifS_h_Hlu4Y_6iODiuCVKVQPfHC6ls2omgh6Wvw=.86047007-c614-4e9e-a948-75b17d885e8e@github.com>
Message-ID: <HAN7K3cb-s3nj-prtAkfeDglHohsD4G0qXrkM2dl670=.1e979e3d-1918-4412-a68d-4b7827cd95cd@github.com>

On Tue, 15 Feb 2022 07:31:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Tests ran through at SAP, patch looks good. Thank you for fixing this!

Thank you for testing the patch.

> Sorry for the slow response, I just saw this. I'll give this a spin in our CI. From the outside it looks good.

@tstuefe, @iklam, @yminqi Thanks for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/7413

From ccheung at openjdk.java.net  Tue Feb 15 17:22:09 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 15 Feb 2022 17:22:09 GMT
Subject: Integrated: 8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails
In-Reply-To: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
References: <nxD51Izz8029MA8odp9oYSCz1OUKTAcWfV21QLlxY0E=.a7b10890-a16a-41db-9a0f-524a7fe0cfd2@github.com>
Message-ID: <HNwuUCnGhTdBsMGnTQu3nTteYlYRYOqqbaYQc8ozVog=.ad9a8729-21ca-4495-9163-8e291985d095@github.com>

On Wed, 9 Feb 2022 23:02:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A simple fix to the test failure by specifying the heap sizes for most of the test cases.
> Before the fix, if the MaxHeapSize is determined by the VM, the MaxHeapSize could become smaller
> than the MinHeapSize or the InitialHeapSize which causing the failure.
> 
> Testing: CI tiers 1 - 4.

This pull request has now been integrated.

Changeset: 745f7e7d
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/745f7e7d921afcf45a2fa87824841e4545054d21
Stats:     23 lines in 1 file changed: 14 ins; 5 del; 4 mod

8281186: runtime/cds/appcds/DumpingWithNoCoops.java fails

Reviewed-by: minqi, iklam, stuefe

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

PR: https://git.openjdk.java.net/jdk/pull/7413

From lmesnik at openjdk.java.net  Tue Feb 15 18:03:11 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 15 Feb 2022 18:03:11 GMT
Subject: Integrated: 8279949: JavaThread::_free_handle_block leaks native
 memory
In-Reply-To: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
References: <-Tk0Gp-BqvAaUoXKjTVLPm5q135GNBDKzphhT7YrFoA=.06e491fd-5623-4c18-a437-c42766bf9e4e@github.com>
Message-ID: <h3zELxm_7zqIsBSCrjfGbS_T1vx5ChTX-VI6z3-QOYQ=.43984179-827f-4ec2-8c94-0bc4e116f8c6@github.com>

On Sat, 12 Feb 2022 22:07:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix which delete whole list of JNIHandle blocks in JNIHandleBlock::release_block(...).
> Also, I added sanity verification of _pop_frame_link to ensure that there are no leaks there.
> 
> Fix verified with tier1-6. Also, verified that memory leak is not reproduced anymore.
> 
> Thanks to Vladimir I.  for finding exact root cause of problem.

This pull request has now been integrated.

Changeset: 1aff44b2
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1aff44b2cfcf5d2253161985b902894ee69365fc
Stats:     10 lines in 1 file changed: 5 ins; 0 del; 5 mod

8279949: JavaThread::_free_handle_block leaks native memory

Reviewed-by: dholmes, coleenp

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

PR: https://git.openjdk.java.net/jdk/pull/7453

From lmesnik at openjdk.java.net  Tue Feb 15 18:05:12 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 15 Feb 2022 18:05:12 GMT
Subject: Integrated: 8281771: Crash in
 java_lang_invoke_MethodType::print_signature
In-Reply-To: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
References: <rg-zogVVMQjOHRGfMDXtWiPp7NsxbwRCaHCVuALOjk8=.976aff5c-ad75-4e3f-9bb8-9ff00a693980@github.com>
Message-ID: <V401YbTICUlGedV-Q6sETC3Gx-av6WQwYS_Bl5FiwCg=.54a8de12-90ec-41b4-9bbe-ed889899d4d7@github.com>

On Tue, 15 Feb 2022 06:43:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The crash happens in java.lang.invoke.MethodType.<init> when VM tries to print this objec while rtype and ptypes are not initialized yet. So the fix is just to check if they are not NULL.

This pull request has now been integrated.

Changeset: a24498b7
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a24498b777b76c04d7e6da0a8b5fb501f2fb4944
Stats:     13 lines in 1 file changed: 9 ins; 0 del; 4 mod

8281771: Crash in java_lang_invoke_MethodType::print_signature

Reviewed-by: dholmes, shade

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

PR: https://git.openjdk.java.net/jdk/pull/7470

From dholmes at openjdk.java.net  Tue Feb 15 22:25:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 15 Feb 2022 22:25:06 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v2]
In-Reply-To: <r5j1bYGT03KgJ-wZ-_U9nQiEjbgdpfaUZwo19HLHdtI=.7e592562-e7c0-49c2-985c-49db6ceea613@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <r5j1bYGT03KgJ-wZ-_U9nQiEjbgdpfaUZwo19HLHdtI=.7e592562-e7c0-49c2-985c-49db6ceea613@github.com>
Message-ID: <lyoQHX_T2RcgdoffwsTsDJNfJ5DNR-8xt43OsjQQaQs=.ccfe7a63-1c04-4105-add0-8041be327b78@github.com>

On Tue, 15 Feb 2022 16:11:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
>> 
>> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
>> 
>> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
>> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>> 
>> 
>> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
>> 
>> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Explicit DTraceOptionsTest
>  - Sense DTrace build option

Yeah that is certainly a lot more changes, the main value of which seems to be for backports given we're even thinking of dropping DTrace support entirely. (I decided not to bother trying to add a "hasDTrace" capability when fixing the issue with the VMDeprecatedOptions test as it was not worth the time and effort IMO).

One query about restricting the test to Linux below - and I'll need to take the final version for a spin in our CI before pushing, but tacit approval.

Thanks,
David

test/hotspot/jtreg/serviceability/dtrace/DTraceOptionsTest.java line 28:

> 26:  * @bug 8281822
> 27:  * @summary Test DTrace options are accepted on suitable builds
> 28:  * @requires os.family == "linux"

macOS should be a possibility too. But if you check explicitly for hasDTrace then you don't also need to limit the platform.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7477

From iklam at openjdk.java.net  Wed Feb 16 05:51:27 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 16 Feb 2022 05:51:27 GMT
Subject: RFR: 8279969: NULL return from map_bitmap_region() needs to be checked
Message-ID: <90dUxkGHMo97YLhkAVw4GomvjPwmVTBwDemUY2w3Ku4=.8f4b23f1-9b56-470c-a029-081f0d0a4606@github.com>

The CDS-related function `FileMapInfo::map_bitmap_region()` could return `NULL` if CRC check fails, or if we run out of memory. There are two call sites of map_bitmap_region() that did not check for `NULL` , and the VM subsequently would crash. However, there was a bug in the test case that ignored such crashes, and we only found out by chance because jtreg timed out while trying to copy the core file.

The fix is to add the missing NULL checks. Also, since `FileMapInfo::patch_heap_embedded_pointers()` cannot handle the mapping failure, I moved the mapping to an earlier stage (`FileMapInfo::map_heap_regions_impl()`) where the error can be handled.

I also added a VM crash check in the test case.

Note: there's a single bitmap region in the CDS archive. It will be mapped on the first call to `FileMapInfo::map_bitmap_region()`, and will remain mapped until after the loading of the CDS archive is completed.

Passed tiers 1-4.

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

Commit messages:
 - 8279969: NULL check missing in HeapShared::load_regions()

Changes: https://git.openjdk.java.net/jdk/pull/7487/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7487&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279969
  Stats: 24 lines in 3 files changed: 21 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7487.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7487/head:pull/7487

PR: https://git.openjdk.java.net/jdk/pull/7487

From shade at openjdk.java.net  Wed Feb 16 06:12:42 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Feb 2022 06:12:42 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v3]
In-Reply-To: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
Message-ID: <7JoiAlLMdQpUNaDnkHFAo4NPu6e2jPgRg1N9wXF3pwI=.a48cfd9d-a2a0-4659-b8cc-a859ca079759@github.com>

> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
> 
> 
> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
> 
> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
> 
> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> 
> 
> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
> 
> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes

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

  Test fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7477/files
  - new: https://git.openjdk.java.net/jdk/pull/7477/files/b799af8c..e7b04df5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7477&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7477&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From shade at openjdk.java.net  Wed Feb 16 06:12:44 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Feb 2022 06:12:44 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v2]
In-Reply-To: <lyoQHX_T2RcgdoffwsTsDJNfJ5DNR-8xt43OsjQQaQs=.ccfe7a63-1c04-4105-add0-8041be327b78@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <r5j1bYGT03KgJ-wZ-_U9nQiEjbgdpfaUZwo19HLHdtI=.7e592562-e7c0-49c2-985c-49db6ceea613@github.com>
 <lyoQHX_T2RcgdoffwsTsDJNfJ5DNR-8xt43OsjQQaQs=.ccfe7a63-1c04-4105-add0-8041be327b78@github.com>
Message-ID: <q63vANLFcn4lbuQ0JK1nuRt5xqJYpJvHG5rfFhfVo6c=.396165e7-f872-404a-9e84-be33d21474ba@github.com>

On Tue, 15 Feb 2022 22:21:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> One query about restricting the test to Linux below - and I'll need to take the final version for a spin in our CI before pushing, but tacit approval.

OK, I am seeing another GHA failure, which is due to another instance `Whitebox` missing a method declaration. I pushed the version that should fix that failure now. Once GHA is green, I'd say the fix is final.

> test/hotspot/jtreg/serviceability/dtrace/DTraceOptionsTest.java line 28:
> 
>> 26:  * @bug 8281822
>> 27:  * @summary Test DTrace options are accepted on suitable builds
>> 28:  * @requires os.family == "linux"
> 
> macOS should be a possibility too. But if you check explicitly for hasDTrace then you don't also need to limit the platform.

Right, fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From dholmes at openjdk.java.net  Wed Feb 16 06:40:03 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Feb 2022 06:40:03 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v3]
In-Reply-To: <7JoiAlLMdQpUNaDnkHFAo4NPu6e2jPgRg1N9wXF3pwI=.a48cfd9d-a2a0-4659-b8cc-a859ca079759@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <7JoiAlLMdQpUNaDnkHFAo4NPu6e2jPgRg1N9wXF3pwI=.a48cfd9d-a2a0-4659-b8cc-a859ca079759@github.com>
Message-ID: <KhN3Vs_I_e9IuwMkK1mDCCQfZ3rlUsca2OwwLAm81tQ=.250ea114-add6-44a6-bc99-c4c4f1a063cf@github.com>

On Wed, 16 Feb 2022 06:12:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
>> 
>> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
>> 
>> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
>> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>> 
>> 
>> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
>> 
>> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fixes

I will run it through our CI and report back.

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From dholmes at openjdk.java.net  Wed Feb 16 07:41:08 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Feb 2022 07:41:08 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v3]
In-Reply-To: <7JoiAlLMdQpUNaDnkHFAo4NPu6e2jPgRg1N9wXF3pwI=.a48cfd9d-a2a0-4659-b8cc-a859ca079759@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <7JoiAlLMdQpUNaDnkHFAo4NPu6e2jPgRg1N9wXF3pwI=.a48cfd9d-a2a0-4659-b8cc-a859ca079759@github.com>
Message-ID: <TsgoDnp1Xvmyww6x8jZR1I_WkFU5djjMw-dT7887-oM=.f186352a-9d7e-4383-aa2c-e71014922694@github.com>

On Wed, 16 Feb 2022 06:12:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
>> 
>> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
>> 
>> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
>> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>> 
>> 
>> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
>> 
>> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fixes

Test change requested - see below.

Also another thought on the fix below.

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

> 2909:     } else if (match_option(option, "-XX:+DTraceMethodProbes")) {
> 2910:       jio_fprintf(defaultStream::error_stream(),
> 2911:                   "DTraceMethodProbes flag is not applicable for this configuration\n");

Looking at this again, in light of the test changes, I have to wonder if the pre-existing treatment of `ExtendedDTraceProbes` was wrong and we should simply have used `UNSUPPORTED_OPTION` in these cases?

test/hotspot/jtreg/compiler/runtime/Test8168712.java line 27:

> 25:  * @test
> 26:  * @requires vm.debug
> 27:  * @requires vm.hasDTrace

DTrace is not critical to this test. IIUC the original fix and test had an issue when combined with DTrace hence the test enabled it to check it was fixed by a further patch. So we actually want to run this test regardless. In which case we need to add another test section for when `!vm.hasDTrace` that doesn't pass the DTrace flag.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7477

From thartmann at openjdk.java.net  Wed Feb 16 07:55:05 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 16 Feb 2022 07:55:05 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467
In-Reply-To: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
Message-ID: <eY0HhKN0ldOiqauto4LzmXYF8IumQFtp5WZkTPHzJ18=.39666ebe-ff05-4765-8c8d-782681e3c9c3@github.com>

On Tue, 15 Feb 2022 14:51:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
> It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.
> 
> This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.
> 
>  824   address generate_fp_mask(const char *stub_name, int64_t mask) {
>  825     __ align(CodeEntryAlignment);
>  826     StubCodeMark mark(this, "StubRoutines", stub_name);
>  827     address start = __ pc();
>  828
>  829     __ emit_data64( mask, relocInfo::none );
>  830     __ emit_data64( mask, relocInfo::none );
>  831
>  832     return start;
>  833   }
> 
> 
> Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.
> 
> 1184 void MacroAssembler::align(int modulus) {
> 1185   // 8273459: Ensure alignment is possible with current segment alignment
> 1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
> 1187   align(modulus, offset());
> 1188 }
> 1189
> 1190 void MacroAssembler::align(int modulus, int target) {
> 1191   if (target % modulus != 0) {
> 1192     nop(modulus - (target % modulus));
> 1193   }
> 1194 }
> 
> 
> The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.
> 
> This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
> And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.
> 
> Thanks.
> Best regards,
> Jie

Looks good to me otherwise.

src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp line 233:

> 231:   if ((uintx)CodeEntryAlignment > CodeCacheSegmentSize) {
> 232:     JVMFlag::printError(verbose,
> 233:                         "CodeEntryAlignment  (" INTX_FORMAT ") must be "

Suggestion:

                        "CodeEntryAlignment (" INTX_FORMAT ") must be "

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7480

From shade at openjdk.java.net  Wed Feb 16 08:03:53 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Feb 2022 08:03:53 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v4]
In-Reply-To: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
Message-ID: <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>

> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
> 
> 
> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
> 
> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
> 
> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> 
> 
> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
> 
> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes

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

  Test8168712 non-dtrace config

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7477/files
  - new: https://git.openjdk.java.net/jdk/pull/7477/files/e7b04df5..5c32815d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7477&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7477&range=02-03

  Stats: 19 lines in 1 file changed: 17 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7477.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7477/head:pull/7477

PR: https://git.openjdk.java.net/jdk/pull/7477

From shade at openjdk.java.net  Wed Feb 16 08:03:57 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Feb 2022 08:03:57 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v3]
In-Reply-To: <TsgoDnp1Xvmyww6x8jZR1I_WkFU5djjMw-dT7887-oM=.f186352a-9d7e-4383-aa2c-e71014922694@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <7JoiAlLMdQpUNaDnkHFAo4NPu6e2jPgRg1N9wXF3pwI=.a48cfd9d-a2a0-4659-b8cc-a859ca079759@github.com>
 <TsgoDnp1Xvmyww6x8jZR1I_WkFU5djjMw-dT7887-oM=.f186352a-9d7e-4383-aa2c-e71014922694@github.com>
Message-ID: <qMl1Y0kvWiYmSkj_XP203x5-nEdEmXam9b5d0MkuKVU=.ab6e27bb-5ff1-4382-a8a5-0dff39dd52ef@github.com>

On Wed, 16 Feb 2022 07:36:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test fixes
>
> src/hotspot/share/runtime/arguments.cpp line 2911:
> 
>> 2909:     } else if (match_option(option, "-XX:+DTraceMethodProbes")) {
>> 2910:       jio_fprintf(defaultStream::error_stream(),
>> 2911:                   "DTraceMethodProbes flag is not applicable for this configuration\n");
> 
> Looking at this again, in light of the test changes, I have to wonder if the pre-existing treatment of `ExtendedDTraceProbes` was wrong and we should simply have used `UNSUPPORTED_OPTION` in these cases?

Maybe, but this block also handles ergonomic opt-in to `DTrace*` flags when `ExtendedDTraceProbe` is enabled, and it matches the style of the similar checks. I'd leave it as is.

> test/hotspot/jtreg/compiler/runtime/Test8168712.java line 27:
> 
>> 25:  * @test
>> 26:  * @requires vm.debug
>> 27:  * @requires vm.hasDTrace
> 
> DTrace is not critical to this test. IIUC the original fix and test had an issue when combined with DTrace hence the test enabled it to check it was fixed by a further patch. So we actually want to run this test regardless. In which case we need to add another test section for when `!vm.hasDTrace` that doesn't pass the DTrace flag.

Right. Added, see new commit.

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From dholmes at openjdk.java.net  Wed Feb 16 08:08:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Feb 2022 08:08:05 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v4]
In-Reply-To: <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
Message-ID: <qH6XncTvVw7Xuz-rJSoi2192gW-ZDM4RbvjLo2bqBw4=.cb3e9cdb-db0c-4041-958f-dd1787c2be79@github.com>

On Wed, 16 Feb 2022 08:03:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
>> 
>> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
>> 
>> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
>> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>> 
>> 
>> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
>> 
>> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test8168712 non-dtrace config

Looks good.

Still waiting for test results - no failures but I need to confirm new tests actually ran. :)

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7477

From dholmes at openjdk.java.net  Wed Feb 16 08:08:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Feb 2022 08:08:05 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v3]
In-Reply-To: <qMl1Y0kvWiYmSkj_XP203x5-nEdEmXam9b5d0MkuKVU=.ab6e27bb-5ff1-4382-a8a5-0dff39dd52ef@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <7JoiAlLMdQpUNaDnkHFAo4NPu6e2jPgRg1N9wXF3pwI=.a48cfd9d-a2a0-4659-b8cc-a859ca079759@github.com>
 <TsgoDnp1Xvmyww6x8jZR1I_WkFU5djjMw-dT7887-oM=.f186352a-9d7e-4383-aa2c-e71014922694@github.com>
 <qMl1Y0kvWiYmSkj_XP203x5-nEdEmXam9b5d0MkuKVU=.ab6e27bb-5ff1-4382-a8a5-0dff39dd52ef@github.com>
Message-ID: <eaq5iyNz-Uzr8eLEjjDH2eQKfoROn0vvbrAVJv6mkdk=.0fd1abfd-5364-49b1-8993-c97c4cf69415@github.com>

On Wed, 16 Feb 2022 08:00:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 2911:
>> 
>>> 2909:     } else if (match_option(option, "-XX:+DTraceMethodProbes")) {
>>> 2910:       jio_fprintf(defaultStream::error_stream(),
>>> 2911:                   "DTraceMethodProbes flag is not applicable for this configuration\n");
>> 
>> Looking at this again, in light of the test changes, I have to wonder if the pre-existing treatment of `ExtendedDTraceProbes` was wrong and we should simply have used `UNSUPPORTED_OPTION` in these cases?
>
> Maybe, but this block also handles ergonomic opt-in to `DTrace*` flags when `ExtendedDTraceProbe` is enabled, and it matches the style of the similar checks. I'd leave it as is.

ok

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From jiefu at openjdk.java.net  Wed Feb 16 08:14:39 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 08:14:39 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467 [v2]
In-Reply-To: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
Message-ID: <Fum6-ZtJBwH895FEGEMadk3A02LdwS0gX2gELZqIofM=.770853fd-2e46-4c5d-bb70-c6078ff95e40@github.com>

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
> It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.
> 
> This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.
> 
>  824   address generate_fp_mask(const char *stub_name, int64_t mask) {
>  825     __ align(CodeEntryAlignment);
>  826     StubCodeMark mark(this, "StubRoutines", stub_name);
>  827     address start = __ pc();
>  828
>  829     __ emit_data64( mask, relocInfo::none );
>  830     __ emit_data64( mask, relocInfo::none );
>  831
>  832     return start;
>  833   }
> 
> 
> Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.
> 
> 1184 void MacroAssembler::align(int modulus) {
> 1185   // 8273459: Ensure alignment is possible with current segment alignment
> 1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
> 1187   align(modulus, offset());
> 1188 }
> 1189
> 1190 void MacroAssembler::align(int modulus, int target) {
> 1191   if (target % modulus != 0) {
> 1192     nop(modulus - (target % modulus));
> 1193   }
> 1194 }
> 
> 
> The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.
> 
> This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
> And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7480/files
  - new: https://git.openjdk.java.net/jdk/pull/7480/files/b39bc8f3..5c274548

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7480&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7480&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7480

From jiefu at openjdk.java.net  Wed Feb 16 08:14:40 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 08:14:40 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467 [v2]
In-Reply-To: <eY0HhKN0ldOiqauto4LzmXYF8IumQFtp5WZkTPHzJ18=.39666ebe-ff05-4765-8c8d-782681e3c9c3@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
 <eY0HhKN0ldOiqauto4LzmXYF8IumQFtp5WZkTPHzJ18=.39666ebe-ff05-4765-8c8d-782681e3c9c3@github.com>
Message-ID: <MPVm9m4ho5b6nqd5KpV5pQ02izsl32C9wG73HyFFdeI=.5db34bbb-b26b-44e5-ba28-7b4382ed2ff6@github.com>

On Wed, 16 Feb 2022 07:51:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment
>
> src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp line 233:
> 
>> 231:   if ((uintx)CodeEntryAlignment > CodeCacheSegmentSize) {
>> 232:     JVMFlag::printError(verbose,
>> 233:                         "CodeEntryAlignment  (" INTX_FORMAT ") must be "
> 
> Suggestion:
> 
>                         "CodeEntryAlignment (" INTX_FORMAT ") must be "

Fixed.

Thanks @vnkozlov and @TobiHartmann for your review.

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

PR: https://git.openjdk.java.net/jdk/pull/7480

From shade at openjdk.java.net  Wed Feb 16 09:47:08 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Feb 2022 09:47:08 GMT
Subject: Integrated: 8281812: x86: Use short jumps in
 TemplateTable::condy_helper
In-Reply-To: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
References: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
Message-ID: <pmnKCOXW71_mIg2PFWFaYAzAGFPI7hrDqfiLw7A5UX0=.19fdab36-348e-49bc-a8e3-1241eae41f85@github.com>

On Tue, 15 Feb 2022 08:57:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8281744](https://bugs.openjdk.java.net/browse/JDK-8281744), this change improves TemplateTable::condy_helper, for the same reason: there are only a few pushes between the jumps, and we can tell MacroAssembler those can be short. There is no significant code that uses condy yet (I think), so the performance improvement for condy is only theoretical. This makes interpreter code a bit more compact, though.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`
>  - [x] Linux x86_32 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`

This pull request has now been integrated.

Changeset: fef5d74d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fef5d74d0e7fb32e3f63e9fbc34c5370e683e451
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8281812: x86: Use short jumps in TemplateTable::condy_helper

Reviewed-by: redestad, neliasso

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

PR: https://git.openjdk.java.net/jdk/pull/7473

From shade at openjdk.java.net  Wed Feb 16 09:47:07 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Feb 2022 09:47:07 GMT
Subject: RFR: 8281812: x86: Use short jumps in TemplateTable::condy_helper
In-Reply-To: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
References: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>
Message-ID: <F3b8RZ5cLE2SNuSyOIDX9sMa1DFW-ExO9zirPli3YsQ=.f7573bbe-7d10-4fcf-9787-72462edc53d3@github.com>

On Tue, 15 Feb 2022 08:57:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Similar to [JDK-8281744](https://bugs.openjdk.java.net/browse/JDK-8281744), this change improves TemplateTable::condy_helper, for the same reason: there are only a few pushes between the jumps, and we can tell MacroAssembler those can be short. There is no significant code that uses condy yet (I think), so the performance improvement for condy is only theoretical. This makes interpreter code a bit more compact, though.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`
>  - [x] Linux x86_32 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`

Thanks for reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/7473

From dholmes at openjdk.java.net  Wed Feb 16 11:43:09 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Feb 2022 11:43:09 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v4]
In-Reply-To: <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
Message-ID: <rsJAeB2oTqkrMrJALSkJ3b7_JsAHfsSC1Soj3WGU6Tw=.122f4d84-187e-4cf4-8701-25b9cc7069e6@github.com>

On Wed, 16 Feb 2022 08:03:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
>> 
>> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
>> 
>> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
>> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>> 
>> 
>> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
>> 
>> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test8168712 non-dtrace config

Tests are fine. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From shade at openjdk.java.net  Wed Feb 16 11:43:09 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Feb 2022 11:43:09 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v4]
In-Reply-To: <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
Message-ID: <RxMTWL5x85F7_Q7Xuy1DhpNaZGdbOz66sbUCtqv6or0=.9c080379-d0f4-4b99-baba-462c8291f484@github.com>

On Wed, 16 Feb 2022 08:03:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
>> 
>> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
>> 
>> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
>> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>> 
>> 
>> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
>> 
>> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test8168712 non-dtrace config

OK, cool. GHA are also green. I'll wait for another reviewer...

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From jiefu at openjdk.java.net  Wed Feb 16 13:50:12 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 13:50:12 GMT
Subject: Integrated: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467
In-Reply-To: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
Message-ID: <eF8OVIOvNLGYV7Z0XcBNFhbgeMZ8v0-s4Igr6GquHrA=.371c9e7d-b6a3-41a4-85cf-cffbebdf667d@github.com>

On Tue, 15 Feb 2022 14:51:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
> It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.
> 
> This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.
> 
>  824   address generate_fp_mask(const char *stub_name, int64_t mask) {
>  825     __ align(CodeEntryAlignment);
>  826     StubCodeMark mark(this, "StubRoutines", stub_name);
>  827     address start = __ pc();
>  828
>  829     __ emit_data64( mask, relocInfo::none );
>  830     __ emit_data64( mask, relocInfo::none );
>  831
>  832     return start;
>  833   }
> 
> 
> Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.
> 
> 1184 void MacroAssembler::align(int modulus) {
> 1185   // 8273459: Ensure alignment is possible with current segment alignment
> 1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
> 1187   align(modulus, offset());
> 1188 }
> 1189
> 1190 void MacroAssembler::align(int modulus, int target) {
> 1191   if (target % modulus != 0) {
> 1192     nop(modulus - (target % modulus));
> 1193   }
> 1194 }
> 
> 
> The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.
> 
> This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
> And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: d5b46665
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d5b466657e29a5338b84fa9acfc1b76bf8c39d61
Stats:     10 lines in 1 file changed: 9 ins; 0 del; 1 mod

8281829: runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after JDK-8281467

Reviewed-by: kvn, thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/7480

From duke at openjdk.java.net  Wed Feb 16 16:18:14 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 16 Feb 2022 16:18:14 GMT
Subject: RFR: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder) [v21]
In-Reply-To: <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
 <lXf9FfZ-mR1_HMmIQO8VhXUMgie36--31yX63rPpK1k=.bdc175f0-52bb-4a02-a19d-11a9b98b7d82@github.com>
Message-ID: <0SQe2dMc-7PQPHB6tpYRY1YyrVMTPVZWbA0rHUhjCsE=.a7043db1-9378-446b-8ba1-df1213a03ce5@github.com>

On Mon, 14 Feb 2022 23:44:40 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
>> 
>> ### Implementation notes and alternatives considered
>> 
>> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
>> 
>> ### Testing
>> 
>> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
>> 
>> ### More notes
>> 
>> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Adds Oracle & IBM copyrights as per guidance from IBM legal team.
>  - Removes incorrect Oracle copyright line from libperfstat_aix.cpp/hpp, and loadlib_aix.hpp
>  - Edit thread_aix.cpp to match thread_linux.cpp in pd_get_top_fram_for_profiling and ...for_signal_handler
>  - Addresses issues from review and other sm fixes
>    
>    - Adds commenting in regards to memory handling by SystemProcess &
>    NetworkInterface classes
>    - Replaces explicit initialization and copy of structs with memcpy
>    and memset as appropriate
>    - Renames internal struct definitions in os_perf_aix
>    - Other minor fixes
>  - Changes macoss -> macosx in problem list
>  - Refactors loadlib_aix: Removes redundant c++ class
>  - Merge branch 'master' into JDK-8203290
>  - Implements JFR on AIX
>    
>    - Implements interfaces from os_perf.hpp in os_perf_aix.cpp
>    - Updates libperfstat_aix to contain functionality needed by os_perf_aix
>    - Implements missing functionality in loadlib_aix (Fixes failure noted
>    by TestNativeLibraies.java)
>    - Removes platform checks for --enable-feature-jfr (Now enable-able on
>    all platforms)
>    - Enables TestNetworkUtilizationEvent.java which now passes on AIX
>    - Updates AIX JavaThread::pd_get_top_frame_for_profiling with changes from Linux

Thanks very much to the many reviewers who helped make this PR happen. Your support is very much appreciated ?? 

I suggest these we /integrate these changes.

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From kvn at openjdk.java.net  Wed Feb 16 17:43:09 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 17:43:09 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v4]
In-Reply-To: <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
Message-ID: <LkTyIuWQoaQbyNNUKokeuSjf8ESRPdKhZkzu6yGWZ14=.9f4888b3-b793-44dd-ae10-fcfacfad0338@github.com>

On Wed, 16 Feb 2022 08:03:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
>> 
>> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
>> 
>> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
>> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>> 
>> 
>> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
>> 
>> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test8168712 non-dtrace config

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7477

From ccheung at openjdk.java.net  Wed Feb 16 18:09:10 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 16 Feb 2022 18:09:10 GMT
Subject: RFR: 8279969: NULL return from map_bitmap_region() needs to be
 checked
In-Reply-To: <90dUxkGHMo97YLhkAVw4GomvjPwmVTBwDemUY2w3Ku4=.8f4b23f1-9b56-470c-a029-081f0d0a4606@github.com>
References: <90dUxkGHMo97YLhkAVw4GomvjPwmVTBwDemUY2w3Ku4=.8f4b23f1-9b56-470c-a029-081f0d0a4606@github.com>
Message-ID: <6FKTfzpLXfkz6J9fRTc3QolCadEr8T6hp9G6kMCY2Ms=.71d511ff-69ef-43d4-80c2-b346529ebb6e@github.com>

On Wed, 16 Feb 2022 05:39:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The CDS-related function `FileMapInfo::map_bitmap_region()` could return `NULL` if CRC check fails, or if we run out of memory. There are two call sites of map_bitmap_region() that did not check for `NULL` , and the VM subsequently would crash. However, there was a bug in the test case that ignored such crashes, and we only found out by chance because jtreg timed out while trying to copy the core file.
> 
> The fix is to add the missing NULL checks. Also, since `FileMapInfo::patch_heap_embedded_pointers()` cannot handle the mapping failure, I moved the mapping to an earlier stage (`FileMapInfo::map_heap_regions_impl()`) where the error can be handled.
> 
> I also added a VM crash check in the test case.
> 
> Note: there's a single bitmap region in the CDS archive. It will be mapped on the first call to `FileMapInfo::map_bitmap_region()`, and will remain mapped until after the loading of the CDS archive is completed.
> 
> Passed tiers 1-4.

LGTM

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7487

From shade at openjdk.java.net  Wed Feb 16 20:12:14 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Feb 2022 20:12:14 GMT
Subject: RFR: 8281822: Test failures on non-DTrace builds due to incomplete
 DTrace* flags handling [v4]
In-Reply-To: <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
 <Eos0vqp9wxs_U89M9imC3CK-D6tFxPiZkc7RpMuIPd4=.2652ebd3-5110-4a29-8aa6-837638978ecc@github.com>
Message-ID: <W5UXyA_CU2gQecb5mOb1F5rSXzfn_-M6aot5cJ1-o68=.0e1390d5-d5ad-4293-a44b-9ca5f56b164e@github.com>

On Wed, 16 Feb 2022 08:03:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
>> 
>> 
>> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
>> 
>> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
>> 
>> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
>> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>> 
>> 
>> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
>> 
>> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test8168712 non-dtrace config

Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From shade at openjdk.java.net  Wed Feb 16 20:12:16 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 16 Feb 2022 20:12:16 GMT
Subject: Integrated: 8281822: Test failures on non-DTrace builds due to
 incomplete DTrace* flags handling
In-Reply-To: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
References: <2o-3I1ilfTM__I5CHuXCeRSCJt9tPMsPGaDgLswMbiw=.f6a33d33-e093-445c-bf22-1e9e9ab3f141@github.com>
Message-ID: <fADCxzLWAigFhLZKgYKwTg8-afRanU07Jqh-6vNGAhs=.68ec528c-1d7c-41db-b451-95b101a48d74@github.com>

On Tue, 15 Feb 2022 11:54:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> A test failure reproduces in GHA in x86_32 mode. Reproduces locally too:
> 
> 
> $ CONF=linux-x86-server-fastdebug make run-test TEST=serviceability/7170638/SDTProbesGNULinuxTest.java
> 
> java.lang.Error: java.lang.RuntimeException: '.note.stapsd' missing from stdout
> 
> at SDTProbesGNULinuxTest.testLibJvm(SDTProbesGNULinuxTest.java:76)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
> 
> 
> The reason is that the new test now enables `DTraceMethodProbes`, `DTraceAllocProbes`, `DTraceMonitorProbes`, but VM never actually checks those options are available. So test thinks dtrace support is there, yet there are no relevant sections in `libjvm.so`, so the test fails. We should extend the argument checks to those three options too.
> 
> Unfortunately, there are tests that do `DTrace*` flags, we should make them sense the build capability, and act accordingly. This simplifies some existing tests too.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug (dtrace enabled), affected test still passes
>  - [x] Linux x86_32 fastdebug (dtrace disabled due to missing dependencies), affected test now passes

This pull request has now been integrated.

Changeset: 847a99b5
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/847a99b53da6b2c82f7cd5f8634aa7bbae8f445e
Stats:     144 lines in 9 files changed: 128 ins; 13 del; 3 mod

8281822: Test failures on non-DTrace builds due to incomplete DTrace* flags handling

Reviewed-by: dholmes, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/7477

From coleenp at openjdk.java.net  Wed Feb 16 23:43:02 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 16 Feb 2022 23:43:02 GMT
Subject: RFR: 8279969: NULL return from map_bitmap_region() needs to be
 checked
In-Reply-To: <90dUxkGHMo97YLhkAVw4GomvjPwmVTBwDemUY2w3Ku4=.8f4b23f1-9b56-470c-a029-081f0d0a4606@github.com>
References: <90dUxkGHMo97YLhkAVw4GomvjPwmVTBwDemUY2w3Ku4=.8f4b23f1-9b56-470c-a029-081f0d0a4606@github.com>
Message-ID: <JIpR2_cG9IkLCHWEgA9NqNy41VC4HT4GgGtZJ5XTUr4=.5400e3f2-12f8-4445-a34a-7b86dfc6cc35@github.com>

On Wed, 16 Feb 2022 05:39:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The CDS-related function `FileMapInfo::map_bitmap_region()` could return `NULL` if CRC check fails, or if we run out of memory. There are two call sites of map_bitmap_region() that did not check for `NULL` , and the VM subsequently would crash. However, there was a bug in the test case that ignored such crashes, and we only found out by chance because jtreg timed out while trying to copy the core file.
> 
> The fix is to add the missing NULL checks. Also, since `FileMapInfo::patch_heap_embedded_pointers()` cannot handle the mapping failure, I moved the mapping to an earlier stage (`FileMapInfo::map_heap_regions_impl()`) where the error can be handled.
> 
> I also added a VM crash check in the test case.
> 
> Note: there's a single bitmap region in the CDS archive. It will be mapped on the first call to `FileMapInfo::map_bitmap_region()`, and will remain mapped until after the loading of the CDS archive is completed.
> 
> Passed tiers 1-4.

Ok, these changes make sense.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7487

From coleenp at openjdk.java.net  Thu Feb 17 00:48:05 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 17 Feb 2022 00:48:05 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3]
In-Reply-To: <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>
Message-ID: <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com>

On Mon, 14 Feb 2022 13:05:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> ClassLoaderDataGraph::classes_do description says:
>> // Walking classes through the ClassLoaderDataGraph include array classes.
>> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reworked do_class_dump

This looks like a nice cleanup!  Thank you for the test and verification that the format is the same.  A couple of minor comments.

src/hotspot/share/services/heapDumper.cpp line 2003:

> 2001: 
> 2002:   // class ID
> 2003:   Klass* klass = k;

I don't think it's necessary to introduce the variable 'klass' since it's not a loop anymore.

src/hotspot/share/services/heapDumper.cpp line 2305:

> 2303:       ClassLoaderDataGraph::classes_do(&locked_dump_class);
> 2304:     }
> 2305:     Universe::basic_type_classes_do(&do_basic_type_array_class_dump);

If this is the last use of this function, you could remove this variant of this function from Universe.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7384

From iklam at openjdk.java.net  Thu Feb 17 06:45:11 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Feb 2022 06:45:11 GMT
Subject: RFR: 8279969: NULL return from map_bitmap_region() needs to be
 checked
In-Reply-To: <6FKTfzpLXfkz6J9fRTc3QolCadEr8T6hp9G6kMCY2Ms=.71d511ff-69ef-43d4-80c2-b346529ebb6e@github.com>
References: <90dUxkGHMo97YLhkAVw4GomvjPwmVTBwDemUY2w3Ku4=.8f4b23f1-9b56-470c-a029-081f0d0a4606@github.com>
 <6FKTfzpLXfkz6J9fRTc3QolCadEr8T6hp9G6kMCY2Ms=.71d511ff-69ef-43d4-80c2-b346529ebb6e@github.com>
Message-ID: <68MNr_6v7RRDsHlpMapWbIbEIna1BBc_VjEM1xb606U=.2df111b7-1d0d-40d5-9607-e52e59bdb4d1@github.com>

On Wed, 16 Feb 2022 18:05:36 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The CDS-related function `FileMapInfo::map_bitmap_region()` could return `NULL` if CRC check fails, or if we run out of memory. There are two call sites of map_bitmap_region() that did not check for `NULL` , and the VM subsequently would crash. However, there was a bug in the test case that ignored such crashes, and we only found out by chance because jtreg timed out while trying to copy the core file.
>> 
>> The fix is to add the missing NULL checks. Also, since `FileMapInfo::patch_heap_embedded_pointers()` cannot handle the mapping failure, I moved the mapping to an earlier stage (`FileMapInfo::map_heap_regions_impl()`) where the error can be handled.
>> 
>> I also added a VM crash check in the test case.
>> 
>> Note: there's a single bitmap region in the CDS archive. It will be mapped on the first call to `FileMapInfo::map_bitmap_region()`, and will remain mapped until after the loading of the CDS archive is completed.
>> 
>> Passed tiers 1-4.
>
> LGTM

Thanks @calvinccheung and @coleenp for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/7487

From iklam at openjdk.java.net  Thu Feb 17 06:45:11 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 17 Feb 2022 06:45:11 GMT
Subject: Integrated: 8279969: NULL return from map_bitmap_region() needs to be
 checked
In-Reply-To: <90dUxkGHMo97YLhkAVw4GomvjPwmVTBwDemUY2w3Ku4=.8f4b23f1-9b56-470c-a029-081f0d0a4606@github.com>
References: <90dUxkGHMo97YLhkAVw4GomvjPwmVTBwDemUY2w3Ku4=.8f4b23f1-9b56-470c-a029-081f0d0a4606@github.com>
Message-ID: <q00KR5Thnnl2SRW1Zf28exDqwnsuQf-9c4ULsHARrcg=.f00e192a-98b2-4ff6-af31-684a03258455@github.com>

On Wed, 16 Feb 2022 05:39:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The CDS-related function `FileMapInfo::map_bitmap_region()` could return `NULL` if CRC check fails, or if we run out of memory. There are two call sites of map_bitmap_region() that did not check for `NULL` , and the VM subsequently would crash. However, there was a bug in the test case that ignored such crashes, and we only found out by chance because jtreg timed out while trying to copy the core file.
> 
> The fix is to add the missing NULL checks. Also, since `FileMapInfo::patch_heap_embedded_pointers()` cannot handle the mapping failure, I moved the mapping to an earlier stage (`FileMapInfo::map_heap_regions_impl()`) where the error can be handled.
> 
> I also added a VM crash check in the test case.
> 
> Note: there's a single bitmap region in the CDS archive. It will be mapped on the first call to `FileMapInfo::map_bitmap_region()`, and will remain mapped until after the loading of the CDS archive is completed.
> 
> Passed tiers 1-4.

This pull request has now been integrated.

Changeset: 1864481d
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1864481df10d2f616cbfdecebf3bebbae04de5e1
Stats:     24 lines in 3 files changed: 21 ins; 2 del; 1 mod

8279969: NULL return from map_bitmap_region() needs to be checked

Reviewed-by: ccheung, coleenp

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

PR: https://git.openjdk.java.net/jdk/pull/7487

From duke at openjdk.java.net  Thu Feb 17 08:53:18 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 17 Feb 2022 08:53:18 GMT
Subject: Integrated: 8203290: [AIX] Check functionality of JDK-8199712 (Flight
 Recorder)
In-Reply-To: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
References: <_3jiNgYvvIiqcXJOA9QlDpwWIDFzCZACf_1K4scmECA=.13f46d23-02af-4fcd-8ba9-223e49c36c0b@github.com>
Message-ID: <duKbwvxYFB-YMRPrPRX8ffBwNVqiWRouRFIXqfS8dNY=.31d60e36-5d16-4c3a-b0a2-5f66e4432b26@github.com>

On Fri, 17 Dec 2021 19:07:54 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> Just in time for the holidays I have completed an implementation of the JFR functionality for AIX. As a side note, this is my first submission to OpenJDK ??
> 
> ### Implementation notes and alternatives considered
> 
> After modifying the build system to allow the --enable-jvm-feature-jfr to work on AIX, my task was to implement the interfaces from os_perf.hpp. The os_perf_aix.cpp implementation that existed was, I believe, a copy of the Linux implementation. A review of the code in that file showed that NetworkInterface, CPUPerformanceInterface, and SystemProcessInterface would require modification to work on AIX. Using the Linux implementation as a guide, I initially expected to use files from the aix procfs like /proc/<pid>/psinfo, and /proc/<pid>/status in a manner similar to the Linux implementation. However, I ended up using libperfstat for all functionality required by the interfaces.
> 
> ### Testing
> 
> Testing for JFR seems to be quite light in the repo both before and after this change. In addition to performing manual testing, I have added some basic sanity checks that ensure events can be created and committed (using jtreg), and performs some basic checks on the results of the interface member functions (using gtest).
> 
> ### More notes
> 
> I've sent an email to the JFR group about a TOC overflow warning I encountered while building (for the release server target). I believe the fix is to pass -qpic=large when using the xlc toolchain, but my modifications to flags-cflags.m4 have not been successful in removing this warning.

This pull request has now been integrated.

Changeset: c0275e18
Author:    Tyler Steele <tyler.steele at ibm.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0275e18b7cb4a01385b79ced46560322aeacc97
Stats:     1230 lines in 10 files changed: 461 ins; 502 del; 267 mod

8203290: [AIX] Check functionality of JDK-8199712 (Flight Recorder)

Implements JFR for AIX

Reviewed-by: erikj, mdoerr, mgronlun, stuefe, ihse

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

PR: https://git.openjdk.java.net/jdk/pull/6885

From amenkov at openjdk.java.net  Thu Feb 17 12:48:11 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 17 Feb 2022 12:48:11 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3]
In-Reply-To: <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>
 <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com>
Message-ID: <p6PTxpVAUwKvPy1DjVsSPIvY2EKJaDCfTbcqW-H9AhQ=.62afdea4-c5d3-4c86-90e3-e2f8d4844e86@github.com>

On Thu, 17 Feb 2022 00:34:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reworked do_class_dump
>
> src/hotspot/share/services/heapDumper.cpp line 2305:
> 
>> 2303:       ClassLoaderDataGraph::classes_do(&locked_dump_class);
>> 2304:     }
>> 2305:     Universe::basic_type_classes_do(&do_basic_type_array_class_dump);
> 
> If this is the last use of this function, you could remove this variant of this function from Universe.

It's still used in JvmtiGetLoadedClasses::getClassLoaderClasses()

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From amenkov at openjdk.java.net  Thu Feb 17 12:54:48 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 17 Feb 2022 12:54:48 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v4]
In-Reply-To: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
Message-ID: <0IUcZUgqXwXyfxYG-zcRIs0EJ2I5BSSTmSN5Yi5o8Ow=.dd0f7675-a4e4-4591-b1d9-27408c881297@github.com>

> ClassLoaderDataGraph::classes_do description says:
> // Walking classes through the ClassLoaderDataGraph include array classes.
> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)

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

  removed unnecessary variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7384/files
  - new: https://git.openjdk.java.net/jdk/pull/7384/files/173a8da8..fcb8b0a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From amenkov at openjdk.java.net  Thu Feb 17 12:54:50 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 17 Feb 2022 12:54:50 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v3]
In-Reply-To: <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>
 <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com>
Message-ID: <uRENXOD-_sLpMzce8at6lZrAtc0kBpntz5P2B7vMyPo=.b7604597-9e3f-4f82-a283-5c542314a2ea@github.com>

On Thu, 17 Feb 2022 00:31:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reworked do_class_dump
>
> src/hotspot/share/services/heapDumper.cpp line 2003:
> 
>> 2001: 
>> 2002:   // class ID
>> 2003:   Klass* klass = k;
> 
> I don't think it's necessary to introduce the variable 'klass' since it's not a loop anymore.

Fixed

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From duke at openjdk.java.net  Thu Feb 17 15:52:52 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Thu, 17 Feb 2022 15:52:52 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v6]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: Review comments resolved

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/4c1d088e..1db31903

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=04-05

  Stats: 175 lines in 1 file changed: 43 ins; 67 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Thu Feb 17 15:52:53 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Thu, 17 Feb 2022 15:52:53 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
 <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
 <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>
 <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>
 <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@github.com>
 <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@github.com>
Message-ID: <k-mqKdvjW5fsIuHomQYgxQI5KnSGtmO2CSFv-TYwbqY=.96384b92-a032-4293-9b38-11009709bdac@github.com>

On Thu, 10 Feb 2022 10:09:24 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>>> > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>>> 
>>> I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>>> 
>> Thanks for digging out the JBS issue for this.
>> 
>>> > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>>> 
>>> I would actually like the following behavior:
>>> 
>>>     * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>>> 
>>>     * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>>> 
>>> 
>>> I think this is close to what we do now.
>>> 
>>> So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>>> 
>>>     * a single 1G page and 256 2m pages for the heap
>>> 
>> 
>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated. 
>> 
>>>     * 128 2m pages for the code cache
>>>       ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>>> 
>>> 
>>> Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>> 
>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>> 
>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes). 
>> 
>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
>
>> > > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>> > 
>> > 
>> > I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>> 
>> Thanks for digging out the JBS issue for this.
>> 
>> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>> > 
>> > 
>> > I would actually like the following behavior:
>> > ```
>> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>> > 
>> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > I think this is close to what we do now.
>> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>> > ```
>> > * a single 1G page and 256 2m pages for the heap
>> > ```
>> 
>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
>> 
>> > ```
>> > * 128 2m pages for the code cache
>> >   ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>> 
>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>> 
>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
>> 
>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
> 
> Hi @kstefanj , @tstuefe 
> 
> Thanks for sharing your views and comments. 
> Please suggest what specific change you want us to do in the patch since it is fixing the already existing functionality.
> 
> Best Regards,
> Swati

> @swati-sha, I took a closer look at the test-case and right now it won't work when run on aarch64? On those systems in our test environment the base page size is 64k and the large page sizes are 2m and 512m. I took it for a spin to see what failures we would get and here it is:
> 
> ```
> [0.001s][info][pagesize] LargePageSizeInBytes is not a valid large page size (1G) using the default large page size: 512M
> [0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
> [0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
> [0.002s][info   ][pagesize] CodeHeap 'non-nmethods':  min=2496K max=5760K base=0x0000fffec55d0000 page_size=64K size=5760K
> [0.002s][info   ][pagesize] CodeHeap 'profiled nmethods':  min=2496K max=120000K base=0x0000fffec5b70000 page_size=64K size=120000K
> [0.002s][info   ][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K max=120000K base=0x0000fffecd0a0000 page_size=64K size=120000K
> [0.002s][info   ][pagesize] Heap:  min=1G max=2G base=0x0000000080000000 page_size=64K size=2G
> [0.002s][info   ][pagesize] Card Table:  min=4194305B max=4194305B base=0x0000fffee0db0000 page_size=64K size=4160K
> [0.003s][info   ][pagesize] Mark Bitmap:  min=64M max=64M base=0x0000fffebc000000 page_size=64K size=64M
> [0.003s][info   ][pagesize] Parallel Compact Data:  min=160K max=160K base=0x0000fffee08b0000 page_size=64K size=192K
> [0.003s][info   ][pagesize] Parallel Compact Data:  min=4M max=4M base=0x0000fffee04b0000 page_size=64K size=4M
> System does not support 1G pages
> Number of 2M pages = 0
> 
> System does not support 1G pages
> Number of reserved 1G pages = -1
> 
> Number of reserved 2M pages = 0
> 
> TestCase1 skipped
> 
> TestCase2 skipped
> 
> Exceptionjava.lang.RuntimeException: System property 'test.jdk' not set. This property is normally set by jtreg. When running test separately, set this property using '-Dtest.jdk=/path/to/jdk'.
> TestCase4 skipped
> 
> ----------System.err:(11/560)----------
> java.lang.AssertionError: Failed 4K page allocation
> 
> 	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:81)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:828)
> ```
> 
> So either we need to make the test more robust to also work without having hard coded page sizes but rather figure them out during the "setup" stage or we need to add a requires to avoid running on aarch64. I would prefer if the test was fixed to get more coverage and testing with different page sizes. Doing the requires could look something like:
> 
> ```
> @requires os.arch=="amd64" | os.arch=="x86_64"
> ```

Hi @kstefanj,

Added the generalized version of testcase. Please review and let me know.

Thanks,
Swati

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From coleenp at openjdk.java.net  Thu Feb 17 16:35:03 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 17 Feb 2022 16:35:03 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v4]
In-Reply-To: <p6PTxpVAUwKvPy1DjVsSPIvY2EKJaDCfTbcqW-H9AhQ=.62afdea4-c5d3-4c86-90e3-e2f8d4844e86@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>
 <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com>
 <p6PTxpVAUwKvPy1DjVsSPIvY2EKJaDCfTbcqW-H9AhQ=.62afdea4-c5d3-4c86-90e3-e2f8d4844e86@github.com>
Message-ID: <l4v-BOjzGvgquNbr74XFFiqmw7_DOuRc5-khn9gCsgk=.ecd32a17-5dcb-4680-8cd6-cd5e0ebce2bf@github.com>

On Thu, 17 Feb 2022 12:45:10 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/services/heapDumper.cpp line 2305:
>> 
>>> 2303:       ClassLoaderDataGraph::classes_do(&locked_dump_class);
>>> 2304:     }
>>> 2305:     Universe::basic_type_classes_do(&do_basic_type_array_class_dump);
>> 
>> If this is the last use of this function, you could remove this variant of this function from Universe.
>
> It's still used in JvmtiGetLoadedClasses::getClassLoaderClasses()

> void Universe::basic_type_classes_do(void f(Klass*)) {
This one is unused.  The other one that takes the Closure is the one that getClassLoaderClasses() calls.

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From amenkov at openjdk.java.net  Thu Feb 17 17:40:19 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 17 Feb 2022 17:40:19 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v4]
In-Reply-To: <l4v-BOjzGvgquNbr74XFFiqmw7_DOuRc5-khn9gCsgk=.ecd32a17-5dcb-4680-8cd6-cd5e0ebce2bf@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <1aQa9Y7IqE2_1ckFoWR6NUpm7ov8YEFUCZPUBqf3jC4=.3f9cfded-1bc4-4afe-bd78-296711446f84@github.com>
 <77E0X2mzMbTvFKN4XS41lNyFUkaaMsk55hOXMjryXn8=.15c198e6-2e68-47e8-b608-f8ab7fe1581d@github.com>
 <p6PTxpVAUwKvPy1DjVsSPIvY2EKJaDCfTbcqW-H9AhQ=.62afdea4-c5d3-4c86-90e3-e2f8d4844e86@github.com>
 <l4v-BOjzGvgquNbr74XFFiqmw7_DOuRc5-khn9gCsgk=.ecd32a17-5dcb-4680-8cd6-cd5e0ebce2bf@github.com>
Message-ID: <fxiz6-ruhw399skXF2FUURHJQkwyEklDSxWMkA6lDF8=.1db960f7-b6f9-4866-8b54-d49c4e9ddfbd@github.com>

On Thu, 17 Feb 2022 16:32:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> It's still used in JvmtiGetLoadedClasses::getClassLoaderClasses()
>
>> void Universe::basic_type_classes_do(void f(Klass*)) {
> This one is unused.  The other one that takes the Closure is the one that getClassLoaderClasses() calls.

I thought we always have 2 version (for function pointer and closure object), Universe::metaspace_pointers_do has only version for closures.
Will remove unused one.

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From amenkov at openjdk.java.net  Thu Feb 17 18:24:47 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 17 Feb 2022 18:24:47 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v5]
In-Reply-To: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
Message-ID: <GzqWmjy5YjfrAPLlZ7ksq0aYQfdHY0OQgf4Ri15htj8=.badbbb18-3a90-4d9a-8ea2-fdd24d01da89@github.com>

> ClassLoaderDataGraph::classes_do description says:
> // Walking classes through the ClassLoaderDataGraph include array classes.
> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)

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

  removed unused Universe::basic_type_classes_do

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7384/files
  - new: https://git.openjdk.java.net/jdk/pull/7384/files/fcb8b0a6..2c787184

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7384&range=03-04

  Stats: 10 lines in 2 files changed: 0 ins; 7 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7384.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7384/head:pull/7384

PR: https://git.openjdk.java.net/jdk/pull/7384

From coleenp at openjdk.java.net  Thu Feb 17 19:29:15 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 17 Feb 2022 19:29:15 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v5]
In-Reply-To: <GzqWmjy5YjfrAPLlZ7ksq0aYQfdHY0OQgf4Ri15htj8=.badbbb18-3a90-4d9a-8ea2-fdd24d01da89@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <GzqWmjy5YjfrAPLlZ7ksq0aYQfdHY0OQgf4Ri15htj8=.badbbb18-3a90-4d9a-8ea2-fdd24d01da89@github.com>
Message-ID: <xmmSm1v8FfoFVAY9td7yc7tXemVmFKSEvXMrKuEdH0E=.c89d502a-4259-459c-b047-c998fe551e1d@github.com>

On Thu, 17 Feb 2022 18:24:47 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> ClassLoaderDataGraph::classes_do description says:
>> // Walking classes through the ClassLoaderDataGraph include array classes.
>> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused Universe::basic_type_classes_do

Thanks!

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7384

From cjplummer at openjdk.java.net  Thu Feb 17 20:55:14 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 17 Feb 2022 20:55:14 GMT
Subject: RFR: 8281267: VM HeapDumper dumps array classes several times [v5]
In-Reply-To: <GzqWmjy5YjfrAPLlZ7ksq0aYQfdHY0OQgf4Ri15htj8=.badbbb18-3a90-4d9a-8ea2-fdd24d01da89@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
 <GzqWmjy5YjfrAPLlZ7ksq0aYQfdHY0OQgf4Ri15htj8=.badbbb18-3a90-4d9a-8ea2-fdd24d01da89@github.com>
Message-ID: <VLL5SvqLLb2QmWyrq7PI0Z6d5qhOnIlAwX8DTDEUdZI=.752b1a50-1064-48b7-994a-f805ae4324de@github.com>

On Thu, 17 Feb 2022 18:24:47 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> ClassLoaderDataGraph::classes_do description says:
>> // Walking classes through the ClassLoaderDataGraph include array classes.
>> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused Universe::basic_type_classes_do

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From dcubed at openjdk.java.net  Thu Feb 17 21:00:31 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Feb 2022 21:00:31 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
Message-ID: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>

A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.

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

Commit messages:
 - 8282075: ProblemList 3 compiler/whitebox tests on macosx-x64

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

PR: https://git.openjdk.java.net/jdk/pull/7523

From bpb at openjdk.java.net  Thu Feb 17 21:00:33 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 17 Feb 2022 21:00:33 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
In-Reply-To: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
References: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
Message-ID: <EcCo2yia0RFEdBcGpJ5BoZpiMtgnqKqDREyOlSSKpwQ=.2056510a-89ed-4a8b-9912-06c40f19b59a@github.com>

On Thu, 17 Feb 2022 20:48:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7523

From dcubed at openjdk.java.net  Thu Feb 17 21:00:35 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Feb 2022 21:00:35 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
In-Reply-To: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
References: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
Message-ID: <0zZ2TNpyG-ptBmfEMte_L-Tmz1mHJUtOt0Yg3PeLOZs=.addb23a7-09a8-4931-a663-433960848051@github.com>

On Thu, 17 Feb 2022 20:48:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.

This pull request has now been integrated.

Changeset: 69fc273f
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/69fc273f202352f74a313c37db0198be2be08616
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8282075: ProblemList 3 compiler/whitebox tests on macosx-x64

Reviewed-by: mikael, bpb

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

PR: https://git.openjdk.java.net/jdk/pull/7523

From mikael at openjdk.java.net  Thu Feb 17 21:00:32 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 17 Feb 2022 21:00:32 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
In-Reply-To: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
References: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
Message-ID: <l5vU7OEUgw05O-gc1BYsZYU8PH8JVCgqdes6HaZTGY4=.7602026f-031f-4464-9ebb-26d54cd5c06b@github.com>

On Thu, 17 Feb 2022 20:48:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.

Marked as reviewed by mikael (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7523

From dcubed at openjdk.java.net  Thu Feb 17 21:00:33 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Feb 2022 21:00:33 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
In-Reply-To: <l5vU7OEUgw05O-gc1BYsZYU8PH8JVCgqdes6HaZTGY4=.7602026f-031f-4464-9ebb-26d54cd5c06b@github.com>
References: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
 <l5vU7OEUgw05O-gc1BYsZYU8PH8JVCgqdes6HaZTGY4=.7602026f-031f-4464-9ebb-26d54cd5c06b@github.com>
Message-ID: <r_0Dg2_m8dSu2FGjRLoRSL-Xoc2Eiz-NS4Ne78tQ6b4=.37f2603c-f52a-465d-838d-72ddc7dabe5b@github.com>

On Thu, 17 Feb 2022 20:53:45 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik and @bplb - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/7523

From amenkov at openjdk.java.net  Fri Feb 18 09:25:57 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Fri, 18 Feb 2022 09:25:57 GMT
Subject: Integrated: 8281267: VM HeapDumper dumps array classes several times
In-Reply-To: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
References: <K_4wt19ElfcZHN629lP1vfuFYemxHEoWx47G3mRl100=.1d2e4826-22ce-468e-9d95-8b7351b70ede@github.com>
Message-ID: <5gfCGRUQ5cBqTu-9a9UGSV9QhgzjaAG4hHpcBGIl-XE=.6cf9af38-84b3-475a-8942-0855c47aef6d@github.com>

On Tue, 8 Feb 2022 16:49:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> ClassLoaderDataGraph::classes_do description says:
> // Walking classes through the ClassLoaderDataGraph include array classes.
> So do_load_class callback should not dump arrays for the classes and dumper doesn't need to call Universe::basic_type_classes_do (array classes for primitive types are also reported by ClassLoaderDataGraph::classes_do)

This pull request has now been integrated.

Changeset: 138a1719
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/138a17195d1695c6faaa156a43624c39c62b141b
Stats:     463 lines in 4 files changed: 348 ins; 73 del; 42 mod

8281267: VM HeapDumper dumps array classes several times

Reviewed-by: cjplummer, coleenp

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

PR: https://git.openjdk.java.net/jdk/pull/7384

From sjohanss at openjdk.java.net  Fri Feb 18 11:43:54 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 18 Feb 2022 11:43:54 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v6]
In-Reply-To: <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@github.com>
Message-ID: <_mEgJViDAowqFXelPzq0JkfA6CSbq_r2gHo1brRzWgo=.e6527f3c-21f8-4bd6-84f2-f7ec553ec62b@github.com>

On Thu, 17 Feb 2022 15:52:52 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved

Thanks for updating the test. Here is a first set of comments. 

I also just realized that even though the test doesn't show as a failure on aarch64 now it is still not working correctly and I think my suggestion to not use arrays to store the page sizes would help. What I see is that we parse the 16G page size and get an AIOOBE: 

Number of available 16777216kB pages = 0
Exceptionjava.lang.ArrayIndexOutOfBoundsException: Index 32 out of bounds for length 32

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 54:

> 52: class MyClass {
> 53:     public static void main(String args[]) {
> 54:     System.out.println("Inside MyClass");

Indent correctly or just remove. I would also prefer if the class had a name that make it belong more to the test. Something like: `ExplicitPageAllocation`. Another alternative would be to even skip this class and just run the test with `-version`.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 71:

> 69:     private static String errorMessage = null;
> 70: 
> 71:     private static final int SIZE=32;

Maybe a more descriptive name, like `MAX_NUMBER_OF_PAGESIZES` or something like that.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 155:

> 153:                     System.out.println("System does not support"+pageSize+"kB pages");
> 154:                     continue;
> 155:                 }

I find these calculations and logic a bit confusing. Some comments would help. I think what you are doing here is to verify that no-one else on the system is using the large pages which is good, but the output "System does not support" feels wrong if the case actually is that all huge pages are used. 

>From what I can tell, in the case when no pages are configured, both free and resv will be 0, thus available will be 0 and the page size will be considered "available", but with a 0 page count.

A simpler approach would just be to check `nr_hugepages` or `free_hugepages` and use their value as available. If it is 0 it is zero we could output something like: 
"No pages configured for page size X"

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 164:

> 162:         // OS vm page size
> 163:         ProcessBuilder processBuilder = new ProcessBuilder();
> 164:         processBuilder.command("getconf", "PAGE_SIZE");

You could use the WhiteBox API to get the default page size to avoid having to start the extra process. You can search the code for `getVMPageSize()` to see other uses.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 188:

> 186: 
> 187:         for (int i = index;i >= vmPageSizeIndex;i--) {
> 188:             if(pageSizes[i]) {

An alternative to this would be to have something like `ArrayList<PageSizeConfig>` to which we only add the configured page sizes. And `PageSizeConfig` would hold both the page size and the number of pages configured for this size. I think that would be slightly easier to follow.

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

Changes requested by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7326

From dcubed at openjdk.java.net  Fri Feb 18 16:28:19 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Feb 2022 16:28:19 GMT
Subject: Integrated: 8282103: fix macosx-generic typo in ProblemList
Message-ID: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>

A trivial change to fix macosx-generic typo in ProblemList.

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

Commit messages:
 - 8282103: fix macosx-generic typo in ProblemList

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

PR: https://git.openjdk.java.net/jdk/pull/7535

From rriggs at openjdk.java.net  Fri Feb 18 16:28:20 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 18 Feb 2022 16:28:20 GMT
Subject: Integrated: 8282103: fix macosx-generic typo in ProblemList
In-Reply-To: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
References: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
Message-ID: <GWrp0T3ZfFsutekSemTuxGzt1DPXPuNquQN62-lNAIE=.569df68e-c01a-4201-b9fb-d3aca08881d3@github.com>

On Fri, 18 Feb 2022 16:19:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial change to fix macosx-generic typo in ProblemList.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7535

From dcubed at openjdk.java.net  Fri Feb 18 16:28:20 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Feb 2022 16:28:20 GMT
Subject: Integrated: 8282103: fix macosx-generic typo in ProblemList
In-Reply-To: <GWrp0T3ZfFsutekSemTuxGzt1DPXPuNquQN62-lNAIE=.569df68e-c01a-4201-b9fb-d3aca08881d3@github.com>
References: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
 <GWrp0T3ZfFsutekSemTuxGzt1DPXPuNquQN62-lNAIE=.569df68e-c01a-4201-b9fb-d3aca08881d3@github.com>
Message-ID: <dDNITaCX542-WmSkgpbEU65rpBELot7K4AHHzqEl9nQ=.dd5cc3d1-ab0f-45bd-a56a-c17a47ddae45@github.com>

On Fri, 18 Feb 2022 16:21:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial change to fix macosx-generic typo in ProblemList.
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/7535

From dcubed at openjdk.java.net  Fri Feb 18 16:28:21 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Feb 2022 16:28:21 GMT
Subject: Integrated: 8282103: fix macosx-generic typo in ProblemList
In-Reply-To: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
References: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
Message-ID: <XHh7hij_vWCAmd2Q5TWTqiG18MmlM1csHiwaKxPm8BI=.fc8110c7-1f3b-42d8-8afb-7e01bc497804@github.com>

On Fri, 18 Feb 2022 16:19:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial change to fix macosx-generic typo in ProblemList.

This pull request has now been integrated.

Changeset: cfbfd9bf
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cfbfd9bf4123452e8bcff0ef7fbc18b14be8638c
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8282103: fix macosx-generic typo in ProblemList

Reviewed-by: rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/7535

From duke at openjdk.java.net  Sat Feb 19 10:21:11 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Sat, 19 Feb 2022 10:21:11 GMT
Subject: RFR: 8281543: Remove unused code/headerfile dtraceAttacher.hpp
Message-ID: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>

`dtraceAttacher.cpp` with all the relevant definitions was deleted [here](https://github.com/openjdk/jdk/commit/071bd521bca2485c6df95c45e4310d39b05bd046)
in connection with [JDK-8244224](https://bugs.openjdk.java.net/browse/JDK-8244224) (Remove the Solaris and SPARC Ports).

I deleted `dtraceAttacher.cpp`, and the 4 include statements of it in 4 `src/hotspot/os/???/attachListener_???.cpp` files.

Ran tests, mostly to check that it still compiles on various platforms.

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

Commit messages:
 - 8281543: Remove unused code/headerfile dtraceAttacher.hpp

Changes: https://git.openjdk.java.net/jdk/pull/7544/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7544&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281543
  Stats: 58 lines in 5 files changed: 0 ins; 55 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7544.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7544/head:pull/7544

PR: https://git.openjdk.java.net/jdk/pull/7544

From dholmes at openjdk.java.net  Sun Feb 20 22:13:47 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 20 Feb 2022 22:13:47 GMT
Subject: RFR: 8281543: Remove unused code/headerfile dtraceAttacher.hpp
In-Reply-To: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>
References: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>
Message-ID: <8CotfCojYyqRQ74C8le8Xc6ELAsq_HcDwPUcB2oPACw=.12073717-f6eb-47ef-82da-3a838008bc77@github.com>

On Sat, 19 Feb 2022 10:15:15 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> `dtraceAttacher.cpp` with all the relevant definitions was deleted [here](https://github.com/openjdk/jdk/commit/071bd521bca2485c6df95c45e4310d39b05bd046)
> in connection with [JDK-8244224](https://bugs.openjdk.java.net/browse/JDK-8244224) (Remove the Solaris and SPARC Ports).
> 
> I deleted `dtraceAttacher.cpp`, and the 4 include statements of it in 4 `src/hotspot/os/???/attachListener_???.cpp` files.
> 
> Ran tests, mostly to check that it still compiles on various platforms.

Hi Emanuel,

This looks good and trivial.

AFAICS the existence of these includes was a mistake in the first place. Only `attachListener_solaris.cpp` actually needed it, but a limitation of the ancient `includeDB` mechanism meant it was listed as needed by all `attachListener_<os_family>.cpp` files. Then when we got rid of `includeDB` and moved to the standard include mechanism, that dependency was expanded to produce an include entry in each file now being fixed.

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/7544

From duke at openjdk.java.net  Mon Feb 21 11:30:38 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 21 Feb 2022 11:30:38 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v7]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: Review comments are resolved

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/1db31903..069cca92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=05-06

  Stats: 55 lines in 1 file changed: 13 ins; 28 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Mon Feb 21 11:36:54 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 21 Feb 2022 11:36:54 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v6]
In-Reply-To: <_mEgJViDAowqFXelPzq0JkfA6CSbq_r2gHo1brRzWgo=.e6527f3c-21f8-4bd6-84f2-f7ec553ec62b@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@github.com>
 <_mEgJViDAowqFXelPzq0JkfA6CSbq_r2gHo1brRzWgo=.e6527f3c-21f8-4bd6-84f2-f7ec553ec62b@github.com>
Message-ID: <6_KP0bELJ48XX83QbiNF4uFY7wVvM9voRXGyyFnu3CY=.44d78fe3-843b-4ab7-bce0-3bc7ffd7c374@github.com>

On Fri, 18 Feb 2022 11:28:06 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8271195: Review comments resolved
>
> test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 188:
> 
>> 186: 
>> 187:         for (int i = index;i >= vmPageSizeIndex;i--) {
>> 188:             if(pageSizes[i]) {
> 
> An alternative to this would be to have something like `ArrayList<PageSizeConfig>` to which we only add the configured page sizes. And `PageSizeConfig` would hold both the page size and the number of pages configured for this size. I think that would be slightly easier to follow.

Page Count array size increased to 64 this will fix the reported issue and should be sufficient to handle all the page sizes for 64 bit platforms.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From sjohanss at openjdk.java.net  Mon Feb 21 12:11:02 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 12:11:02 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v7]
In-Reply-To: <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@github.com>
Message-ID: <2hNQeAECiO0A6N4jCPBpVgPtK2cMXkK-THnYz2ArEkU=.f89c3cb9-5e0f-41ba-be4a-f360c7130355@github.com>

On Mon, 21 Feb 2022 11:30:38 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments are resolved

I'm currently running the latest test through our testing to make sure everything is fine.

Sorry for the many suggestions, I didn't expect it to be so many. Please take another look through the code as well, I might have missed some additional places where spaces should be added to use the same format as the rest of the file and other tests.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 61:

> 59: 
> 60:     private static final String DIR_HUGE_PAGES = "/sys/kernel/mm/hugepages/";
> 61:     private static final int HEAP_SIZE_IN_KB = 1 * 1024 *1024;

Suggestion:

    private static final int HEAP_SIZE_IN_KB = 1 * 1024 * 1024;

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 71:

> 69:     private static String errorMessage = null;
> 70: 
> 71:     private static final int MAX_NUMBER_OF_PAGESIZE=64;

Suggestion:

    private static final int MAX_NUMBER_OF_PAGESIZE = 64;

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 80:

> 78:         try {
> 79:             doSetup();
> 80:             for (int i = MAX_NUMBER_OF_PAGESIZE-1;i > vmPageSizeIndex;i--) {

Suggestion:

            for (int i = MAX_NUMBER_OF_PAGESIZE - 1; i > vmPageSizeIndex; i--) {

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 87:

> 85:             }
> 86:         } catch(Exception e) {
> 87:            System.out.println("Exception"+e);

Suggestion:

           System.out.println("Exception" + e);

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 109:

> 107:         else
> 108:            return Integer.toString(sizeInBytes/g)+"G";
> 109:     }

Suggestion:

    private static int requiredPageCount(int index) {
        int pageSizeInKB = 1 << (index - 10);
        return HEAP_SIZE_IN_KB / pageSizeInKB;
    }

    private static String sizeFromIndex(int index) {
        int k = 1024;
        int m = 1024 * 1024;
        int g = 1024 * 1024 * 1024;
        int sizeInBytes = 1 << index;
        if (sizeInBytes < m)
           return Integer.toString(sizeInBytes / k) + "K";
        if(sizeInBytes < g)
           return Integer.toString(sizeInBytes / m) + "M";
        else
           return Integer.toString(sizeInBytes / g) + "G";
    }

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 150:

> 148:                 System.out.println("No Pages configured for "+pageSize+"kB");
> 149:             }
> 150:             int index = Integer.numberOfTrailingZeros(Integer.parseInt(pageSize)*1024);

Suggestion:

            int availablePages = checkAndReadFile(DIR_HUGE_PAGES + pageSizeFileName + "/free_hugepages", pageSize);
            if (availablePages == 0) {
                System.out.println("No Pages configured for " + pageSize + "kB");
            }
            int index = Integer.numberOfTrailingZeros(Integer.parseInt(pageSize) * 1024);

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 171:

> 169:         OutputAnalyzer output = new OutputAnalyzer(pb.start());
> 170:         output.shouldHaveExitValue(0);
> 171:         for (int i = index;i >= vmPageSizeIndex;i--) {

Suggestion:

        for (int i = index; i >= vmPageSizeIndex; i--) {

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 179:

> 177:                        continue;
> 178:                     }
> 179:                     errorMessage += "TestCase Failed for "+size+" page allocation\n";

Suggestion:

                    errorMessage += "TestCase Failed for " + size + " page allocation\n";

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 181:

> 179:                     errorMessage += "TestCase Failed for "+size+" page allocation\n";
> 180:                 } else {
> 181:                     System.out.println("TestCase Passed for pagesize: "+pageSize+", allocated pagesize:"+size);

Suggestion:

                    System.out.println("TestCase Passed for pagesize: " + pageSize + ", allocated pagesize:" + size);

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 188:

> 186:         }
> 187: 
> 188:         if (errorMessage!=null) {

Suggestion:

        if (errorMessage != null) {

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

Changes requested by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7326

From sjohanss at openjdk.java.net  Mon Feb 21 12:11:03 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 12:11:03 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v6]
In-Reply-To: <6_KP0bELJ48XX83QbiNF4uFY7wVvM9voRXGyyFnu3CY=.44d78fe3-843b-4ab7-bce0-3bc7ffd7c374@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@github.com>
 <_mEgJViDAowqFXelPzq0JkfA6CSbq_r2gHo1brRzWgo=.e6527f3c-21f8-4bd6-84f2-f7ec553ec62b@github.com>
 <6_KP0bELJ48XX83QbiNF4uFY7wVvM9voRXGyyFnu3CY=.44d78fe3-843b-4ab7-bce0-3bc7ffd7c374@github.com>
Message-ID: <6IhfJFLWDkTtm0tqDEj68Cj2Fjx6DbsXZcf-ekWmr6E=.94b9270c-a41a-4087-b628-71d192d473e7@github.com>

On Mon, 21 Feb 2022 11:33:24 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 188:
>> 
>>> 186: 
>>> 187:         for (int i = index;i >= vmPageSizeIndex;i--) {
>>> 188:             if(pageSizes[i]) {
>> 
>> An alternative to this would be to have something like `ArrayList<PageSizeConfig>` to which we only add the configured page sizes. And `PageSizeConfig` would hold both the page size and the number of pages configured for this size. I think that would be slightly easier to follow.
>
> Page Count array size increased to 64 this will fix the reported issue and should be sufficient to handle all the page sizes for 64 bit platforms.

Yes, I saw the fix and it will work. I still think a solution like the one I proposed would be both more robust and easier to maintain, but I you prefer this approach I won't block it.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Mon Feb 21 12:25:53 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 21 Feb 2022 12:25:53 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
Message-ID: <LOqSYbJW_yMxPnGneUeZPQCk0I3ughaPJKicqyjYkmE=.712bf56c-04a8-49bb-84ae-9da9b7189a61@github.com>

On Mon, 24 Jan 2022 02:21:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Analysing the code and its use (see JBS issue for gory details) we can see that `thread_from_jni_environment` can never actually return NULL, so we change it to not appear to do so and thus keep static analysis tools happy.  We also always validate the incoming JNIEnv for debug builds and scrap the unused `VerifyJNIEnvThread` flag.
>> 
>> Testing: tiers 1-5
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

This seems to break `AsyncGetCallTrace` in some rare cases.

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From duke at openjdk.java.net  Mon Feb 21 12:32:52 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 21 Feb 2022 12:32:52 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
Message-ID: <RBA3wTM8PsAtg0Y11tDmopxBpHwkSD2SYMmuhMbB1Gg=.9e8fbf0b-341e-43e0-8e8c-9694d2b7290b@github.com>

On Mon, 24 Jan 2022 02:21:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Analysing the code and its use (see JBS issue for gory details) we can see that `thread_from_jni_environment` can never actually return NULL, so we change it to not appear to do so and thus keep static analysis tools happy.  We also always validate the incoming JNIEnv for debug builds and scrap the unused `VerifyJNIEnvThread` flag.
>> 
>> Testing: tiers 1-5
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

I would suggest to add a method for checking the termination status in cases where it might happen:

```c++
  // Returns whether current thread as indicated by the given JNIEnv
  // is terminated.
  // We don't assert it is Thread::current here as that is done at the
  // external JNI entry points where the JNIEnv is passed into the VM.
  static bool is_thread_from_jni_environment_terminated(JNIEnv* env) {
    JavaThread* current = (JavaThread*)((intptr_t)env - in_bytes(jni_environment_offset()));
    // We can't get here in a thread that has completed its execution and so
    // "is_terminated", but a thread is also considered terminated if the VM
    // has exited, so we have to check this and block in case this is a daemon
    // thread returning to the VM (the JNI DirectBuffer entry points rely on
    // this).
    return current->is_terminated();
  }

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From sjohanss at openjdk.java.net  Mon Feb 21 12:34:53 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 12:34:53 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v7]
In-Reply-To: <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@github.com>
Message-ID: <tiKQscnhO69F3cJviY2kEpWThzQic0AjU1Q30B7lxFA=.14a52e9e-c639-4331-b20e-ef21cec8fef0@github.com>

On Mon, 21 Feb 2022 11:30:38 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments are resolved

Missing `;` made test compilation fail, so re-starting test again.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 130:

> 128:     public static int checkAndReadFile(String filename, String pageSize) throws Exception {
> 129:         fis = new FileInputStream(filename);
> 130:         dis = new DataInputStream(fis)

Suggestion:

        dis = new DataInputStream(fis);

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

Changes requested by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7326

From dholmes at openjdk.java.net  Mon Feb 21 12:43:55 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Feb 2022 12:43:55 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <RBA3wTM8PsAtg0Y11tDmopxBpHwkSD2SYMmuhMbB1Gg=.9e8fbf0b-341e-43e0-8e8c-9694d2b7290b@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
 <RBA3wTM8PsAtg0Y11tDmopxBpHwkSD2SYMmuhMbB1Gg=.9e8fbf0b-341e-43e0-8e8c-9694d2b7290b@github.com>
Message-ID: <9crhYCee3qUowsFMPQZzutrhDqQW3M5oF73oSN3csdY=.2e4e00a9-541e-4bff-bdc3-b885b40dfe3d@github.com>

On Mon, 21 Feb 2022 12:29:34 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright
>
> I would suggest to add a method for checking the termination status in cases where it might happen:
> 
> ```c++
>   // Returns whether current thread as indicated by the given JNIEnv
>   // is terminated.
>   // We don't assert it is Thread::current here as that is done at the
>   // external JNI entry points where the JNIEnv is passed into the VM.
>   static bool is_thread_from_jni_environment_terminated(JNIEnv* env) {
>     JavaThread* current = (JavaThread*)((intptr_t)env - in_bytes(jni_environment_offset()));
>     // We can't get here in a thread that has completed its execution and so
>     // "is_terminated", but a thread is also considered terminated if the VM
>     // has exited, so we have to check this and block in case this is a daemon
>     // thread returning to the VM (the JNI DirectBuffer entry points rely on
>     // this).
>     return current->is_terminated();
>   }

@parttimenerd ?? 
> This seems to break AsyncGetCallTrace in some rare cases, as "thread_from_jni_environment can never actually return NULL" does not always hold.

Can you please provide further information. As a correctly used JNIEnv can never produce a NULL thread as the JNIEnv is a sub-object of the JavaThread instance.

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From duke at openjdk.java.net  Mon Feb 21 12:48:59 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 21 Feb 2022 12:48:59 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
Message-ID: <vtwns50_V5--78-fqlKm4EdFA0zV9Rrr4TfPxHYmgJY=.66d83497-6f61-4eba-855e-a952b7f6b777@github.com>

On Mon, 24 Jan 2022 02:21:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Analysing the code and its use (see JBS issue for gory details) we can see that `thread_from_jni_environment` can never actually return NULL, so we change it to not appear to do so and thus keep static analysis tools happy.  We also always validate the incoming JNIEnv for debug builds and scrap the unused `VerifyJNIEnvThread` flag.
>> 
>> Testing: tiers 1-5
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

AsyncGetCallTrace is implemented in [forte.cpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/forte.cpp):


void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) {
  JavaThread* thread;

  if (trace->env_id == NULL ||
    (thread = JavaThread::thread_from_jni_environment(trace->env_id)) == NULL ||
    thread->is_exiting()) {

    // bad env_id, thread has exited or thread is exiting
    trace->num_frames = ticks_thread_exit; // -8
    return;
  }


I'm going to create a separate issue with a PR for the discussion.

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From dholmes at openjdk.java.net  Mon Feb 21 13:10:56 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Feb 2022 13:10:56 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
Message-ID: <5ks3eef5uGf2yhaAyyKrle-fpulTUhURZnRhIwqN98o=.33d3aa53-7176-42c7-802f-0ca7f61d2ef9@github.com>

On Mon, 24 Jan 2022 02:21:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Analysing the code and its use (see JBS issue for gory details) we can see that `thread_from_jni_environment` can never actually return NULL, so we change it to not appear to do so and thus keep static analysis tools happy.  We also always validate the incoming JNIEnv for debug builds and scrap the unused `VerifyJNIEnvThread` flag.
>> 
>> Testing: tiers 1-5
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

That condition should just be:

if (trace->env_id == NULL || (thread = JavaThread::thread_from_jni_environment(trace->env_id))->is_exiting()) {

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From duke at openjdk.java.net  Mon Feb 21 13:10:56 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 21 Feb 2022 13:10:56 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
Message-ID: <0dYN9ybKosu-ctb7uJmGB_OMJhRwVmpt6uWErzOJ-zw=.d6dc3661-59df-4b70-921a-b77bcd75adc9@github.com>

On Mon, 24 Jan 2022 02:21:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Analysing the code and its use (see JBS issue for gory details) we can see that `thread_from_jni_environment` can never actually return NULL, so we change it to not appear to do so and thus keep static analysis tools happy.  We also always validate the incoming JNIEnv for debug builds and scrap the unused `VerifyJNIEnvThread` flag.
>> 
>> Testing: tiers 1-5
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

That does not address the issue, as `JavaThread::thread_from_jni_environment(trace->env_id)` never returns in case `is_terminating()` returns true.

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From duke at openjdk.java.net  Mon Feb 21 13:11:39 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 21 Feb 2022 13:11:39 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v8]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: Review comments resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/069cca92..f0e9d901

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=06-07

  Stats: 29 lines in 3 files changed: 0 ins; 3 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From dholmes at openjdk.java.net  Mon Feb 21 13:25:54 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Feb 2022 13:25:54 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
Message-ID: <MsmeLNou2vm2y3Qwr574dSz2C_8V9Md8Gii5jEqj560=.eb170ede-d3d3-4290-ad54-8f6f40b45f81@github.com>

On Mon, 24 Jan 2022 02:21:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Analysing the code and its use (see JBS issue for gory details) we can see that `thread_from_jni_environment` can never actually return NULL, so we change it to not appear to do so and thus keep static analysis tools happy.  We also always validate the incoming JNIEnv for debug builds and scrap the unused `VerifyJNIEnvThread` flag.
>> 
>> Testing: tiers 1-5
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Correct but this PR did not introduce that behaviour. I only changed the name of the local variable and added the comment.

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From duke at openjdk.java.net  Mon Feb 21 13:25:55 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 21 Feb 2022 13:25:55 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
Message-ID: <sgHUTn9O0U60KPT04F5-nb4iNipZ_ZlPFSU_Hkn-9bM=.217855e6-fcd9-436f-8ba0-1afd1b50d8db@github.com>

On Mon, 24 Jan 2022 02:21:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Analysing the code and its use (see JBS issue for gory details) we can see that `thread_from_jni_environment` can never actually return NULL, so we change it to not appear to do so and thus keep static analysis tools happy.  We also always validate the incoming JNIEnv for debug builds and scrap the unused `VerifyJNIEnvThread` flag.
>> 
>> Testing: tiers 1-5
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

It seems to me that this commit introduces the `ShouldNotReachHere()` when before `NULL` would be returned.

src/hotspot/share/runtime/thread.hpp line 1327:

> 1325:     if (current->is_terminated()) {
> 1326:       current->block_if_vm_exited();
> 1327:       ShouldNotReachHere();

This breaks AsyncGetCallTrace

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From dholmes at openjdk.java.net  Mon Feb 21 13:41:53 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Feb 2022 13:41:53 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <sgHUTn9O0U60KPT04F5-nb4iNipZ_ZlPFSU_Hkn-9bM=.217855e6-fcd9-436f-8ba0-1afd1b50d8db@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
 <sgHUTn9O0U60KPT04F5-nb4iNipZ_ZlPFSU_Hkn-9bM=.217855e6-fcd9-436f-8ba0-1afd1b50d8db@github.com>
Message-ID: <l41xF_GvwQ32ojVI6MwvgMmYM0lAqYohmwfgkW5qoQQ=.a81861b7-f0ef-4c97-9b23-ac06c25c34e5@github.com>

On Mon, 21 Feb 2022 13:21:21 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright
>
> src/hotspot/share/runtime/thread.hpp line 1327:
> 
>> 1325:     if (current->is_terminated()) {
>> 1326:       current->block_if_vm_exited();
>> 1327:       ShouldNotReachHere();
> 
> This breaks AsyncGetCallTrace

If we reach that code then the VM aborts. It should be impossible to reach that statement and thus impossible to actually return NULL in the old code. Please elaborate under what conditions you think this code can be reached.

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From duke at openjdk.java.net  Mon Feb 21 13:41:53 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 21 Feb 2022 13:41:53 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <l41xF_GvwQ32ojVI6MwvgMmYM0lAqYohmwfgkW5qoQQ=.a81861b7-f0ef-4c97-9b23-ac06c25c34e5@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
 <sgHUTn9O0U60KPT04F5-nb4iNipZ_ZlPFSU_Hkn-9bM=.217855e6-fcd9-436f-8ba0-1afd1b50d8db@github.com>
 <l41xF_GvwQ32ojVI6MwvgMmYM0lAqYohmwfgkW5qoQQ=.a81861b7-f0ef-4c97-9b23-ac06c25c34e5@github.com>
Message-ID: <I54Yzk2tT_3paSO-PK197ZTCkjO0yNo3KbEmXt-56-M=.2b148599-7d94-46f9-a298-503fa0ffabda@github.com>

On Mon, 21 Feb 2022 13:36:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 1327:
>> 
>>> 1325:     if (current->is_terminated()) {
>>> 1326:       current->block_if_vm_exited();
>>> 1327:       ShouldNotReachHere();
>> 
>> This breaks AsyncGetCallTrace
>
> If we reach that code then the VM aborts. It should be impossible to reach that statement and thus impossible to actually return NULL in the old code. Please elaborate under what conditions you think this code can be reached.

AsyncProfiler on a debug build of OpenJDK profiling the dacapo tomcat benchmark.

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From sjohanss at openjdk.java.net  Mon Feb 21 14:09:53 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 14:09:53 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v8]
In-Reply-To: <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@github.com>
Message-ID: <VJRbTlymlQ1OqvN1d0J2HFO1MprnbWxZotdfOKWPpZA=.ce554e61-a9c0-492a-8351-5f1862364a30@github.com>

On Mon, 21 Feb 2022 13:11:39 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

Test is still failing on aarch64. I really encourage you to consider doing a simpler approach like the one I've suggested instead of storing the page sizes as index in an array. I find the current version hard to debug and I don't really see any benefit of the array compared to a list that can be sorted to get decreasing order.

Below is the output from the failure, I've removed a lot. Looks strange to run the test with `LargePageSizeInBytes=0K`, so I expect an unexpected value has been added to the array: 

No Pages configured for 16777216kB
No Pages configured for 2048kB
No Pages configured for 524288kB
Command line: [ ... -Xlog:pagesize -XX:LargePageSizeInBytes=0K -XX:+UseParallelGC -XX:+UseLargePages -Xmx2g -Xms1g -version ]
...
Checking allocation for 64K
[0.001s][info][pagesize] Using the default large page size: 512M
[0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
[0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
[0.002s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
[0.003s][info   ][pagesize] CodeHeap 'non-nmethods':  min=2496K max=5760K base=0x0000fffea55d0000 page_size=64K size=5760K
[0.012s][info   ][pagesize] CodeHeap 'profiled nmethods':  min=2496K max=120000K base=0x0000fffea5b70000 page_size=64K size=120000K
[0.022s][info   ][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K max=120000K base=0x0000fffead0a0000 page_size=64K size=120000K
[0.032s][info   ][pagesize] Heap:  min=1G max=2G base=0x0000000080000000 page_size=64K size=2G
TestCase Passed for pagesize: 0K, allocated pagesize:64K
----------System.err:(14/802)----------
java.lang.AssertionError: nullTestCase Failed for 0K page allocation

	at runtime.os.TestExplicitPageAllocation.testCase(TestExplicitPageAllocation.java:189)
	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:82)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:828)

JavaTest Message: Test threw exception: java.lang.AssertionError: nullTestCase Failed for 0K page allocation

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.AssertionError: nullTestCase Failed for 0K page allocation

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Mon Feb 21 14:49:53 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 21 Feb 2022 14:49:53 GMT
Subject: RFR: 8280422: thread_from_jni_environment can never return NULL
 [v2]
In-Reply-To: <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
References: <TvsQvXm1qLk7jPgo40aUSONiKrRgN9ld2_Vy7WOhHA4=.38ef4b97-aa99-45a4-8fbe-2770bfd7ea31@github.com>
 <HrzT2CrtZF9dwiLnSA6ckUmCoRe-22eNHbQWK1yDmV4=.bfdc4625-33f5-4a21-923e-a5a0447981b9@github.com>
Message-ID: <G_mHwTdASAiQzq47DHqdrgIoc_iAe2CPmtfqCh2Ya34=.ca0c373c-0ea5-496e-983b-0bbf99de3b72@github.com>

On Mon, 24 Jan 2022 02:21:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Analysing the code and its use (see JBS issue for gory details) we can see that `thread_from_jni_environment` can never actually return NULL, so we change it to not appear to do so and thus keep static analysis tools happy.  We also always validate the incoming JNIEnv for debug builds and scrap the unused `VerifyJNIEnvThread` flag.
>> 
>> Testing: tiers 1-5
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

I've created a PR with a fix at https://github.com/openjdk/jdk/pull/7559

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

PR: https://git.openjdk.java.net/jdk/pull/7193

From sjohanss at openjdk.java.net  Mon Feb 21 15:07:55 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 15:07:55 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v8]
In-Reply-To: <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@github.com>
Message-ID: <krBYp8l33TbyH5FTjTV47BvNUvD6V2vn_4wd2zMCWLQ=.dac47dbb-d04b-4bf0-8b77-e8641a31ce87@github.com>

On Mon, 21 Feb 2022 13:11:39 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Review comments resolved.

Spent some more time on the test-failure and the below overflows are the reasons. 

I think this really shows that we should go with a simpler approach and avoiding the unnecessary bit-fiddling.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 101:

> 99:         int m = 1024 * 1024;
> 100:         int g = 1024 * 1024 * 1024;
> 101:         int sizeInBytes = 1 << index;

The reason for the failing test is that this shift overflow when the page size is 16G. Because of the other overflow the passed in index here was also incorrect (32), but still to large to work properly.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 149:

> 147:                 System.out.println("No Pages configured for " + pageSize + "kB");
> 148:             }
> 149:             int index = Integer.numberOfTrailingZeros(Integer.parseInt(pageSize) * 1024);

The calculation inside the call to `numberOfTrailingZeros()` will overflow when the page-size is 16G (above 1G).

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From djelinski at openjdk.java.net  Tue Feb 22 07:16:13 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 07:16:13 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
Message-ID: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>

Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.

This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).

The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.

I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

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

Commit messages:
 - Strict strings

Changes: https://git.openjdk.java.net/jdk/pull/7565/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7565&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281525
  Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7565.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7565/head:pull/7565

PR: https://git.openjdk.java.net/jdk/pull/7565

From thartmann at openjdk.java.net  Tue Feb 22 07:29:53 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Feb 2022 07:29:53 GMT
Subject: RFR: 8281543: Remove unused code/headerfile dtraceAttacher.hpp
In-Reply-To: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>
References: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>
Message-ID: <EDBfmxkllEtsV5oifSO6GHQKzOoNaGcWgKW7oAVtVz8=.f8dce775-55b5-4f22-86f1-ac32ee819805@github.com>

On Sat, 19 Feb 2022 10:15:15 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> `dtraceAttacher.cpp` with all the relevant definitions was deleted [here](https://github.com/openjdk/jdk/commit/071bd521bca2485c6df95c45e4310d39b05bd046)
> in connection with [JDK-8244224](https://bugs.openjdk.java.net/browse/JDK-8244224) (Remove the Solaris and SPARC Ports).
> 
> I deleted `dtraceAttacher.cpp`, and the 4 include statements of it in 4 `src/hotspot/os/???/attachListener_???.cpp` files.
> 
> Ran tests, mostly to check that it still compiles on various platforms.

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7544

From duke at openjdk.java.net  Tue Feb 22 07:32:46 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Tue, 22 Feb 2022 07:32:46 GMT
Subject: RFR: 8281543: Remove unused code/headerfile dtraceAttacher.hpp
In-Reply-To: <8CotfCojYyqRQ74C8le8Xc6ELAsq_HcDwPUcB2oPACw=.12073717-f6eb-47ef-82da-3a838008bc77@github.com>
References: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>
 <8CotfCojYyqRQ74C8le8Xc6ELAsq_HcDwPUcB2oPACw=.12073717-f6eb-47ef-82da-3a838008bc77@github.com>
Message-ID: <dxCQqnndeJaSjCJfKZmZr3kwCpHg1MobF58DPBJMAQM=.c43d3a40-3f50-44b3-a1c1-648a7b37bbfa@github.com>

On Sun, 20 Feb 2022 22:11:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> `dtraceAttacher.cpp` with all the relevant definitions was deleted [here](https://github.com/openjdk/jdk/commit/071bd521bca2485c6df95c45e4310d39b05bd046)
>> in connection with [JDK-8244224](https://bugs.openjdk.java.net/browse/JDK-8244224) (Remove the Solaris and SPARC Ports).
>> 
>> I deleted `dtraceAttacher.cpp`, and the 4 include statements of it in 4 `src/hotspot/os/???/attachListener_???.cpp` files.
>> 
>> Ran tests, mostly to check that it still compiles on various platforms.
>
> Hi Emanuel,
> 
> This looks good and trivial.
> 
> AFAICS the existence of these includes was a mistake in the first place. Only `attachListener_solaris.cpp` actually needed it, but a limitation of the ancient `includeDB` mechanism meant it was listed as needed by all `attachListener_<os_family>.cpp` files. Then when we got rid of `includeDB` and moved to the standard include mechanism, that dependency was expanded to produce an include entry in each file now being fixed.
> 
> Cheers,
> David

Thanks @dholmes-ora @TobiHartmann for the reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/7544

From duke at openjdk.java.net  Tue Feb 22 07:58:47 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Tue, 22 Feb 2022 07:58:47 GMT
Subject: Integrated: 8281543: Remove unused code/headerfile dtraceAttacher.hpp
In-Reply-To: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>
References: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>
Message-ID: <cMYFN7zvFlCq6XPRy1ng7hNHiUXC6hItSW3usTA0i0A=.d19dc0bc-919e-4ece-b75e-0491c7ab2238@github.com>

On Sat, 19 Feb 2022 10:15:15 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> `dtraceAttacher.cpp` with all the relevant definitions was deleted [here](https://github.com/openjdk/jdk/commit/071bd521bca2485c6df95c45e4310d39b05bd046)
> in connection with [JDK-8244224](https://bugs.openjdk.java.net/browse/JDK-8244224) (Remove the Solaris and SPARC Ports).
> 
> I deleted `dtraceAttacher.cpp`, and the 4 include statements of it in 4 `src/hotspot/os/???/attachListener_???.cpp` files.
> 
> Ran tests, mostly to check that it still compiles on various platforms.

This pull request has now been integrated.

Changeset: bc43320f
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bc43320fd32debf863f37dc00ef7b95589f576ed
Stats:     58 lines in 5 files changed: 0 ins; 55 del; 3 mod

8281543: Remove unused code/headerfile dtraceAttacher.hpp

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/jdk/pull/7544

From ihse at openjdk.java.net  Tue Feb 22 11:36:52 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 11:36:52 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

make/autoconf/flags-cflags.m4 line 136:

> 134:       CFLAGS_WARNINGS_ARE_ERRORS="-WX"
> 135: 
> 136:       WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"

This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK.

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

PR: https://git.openjdk.java.net/jdk/pull/7565

From dholmes at openjdk.java.net  Tue Feb 22 11:58:55 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Feb 2022 11:58:55 GMT
Subject: RFR: 8281543: Remove unused code/headerfile dtraceAttacher.hpp
In-Reply-To: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>
References: <kTrOylTxabG-9pmY-rhI5hD7GTY8TAvTfNebNSawKsE=.b5dde3ce-2f13-4854-a9cd-49751d30cb92@github.com>
Message-ID: <dPFBUDqVw52XKiQTHWIp-HXVa3nur5qHV7mdb9zSt5A=.367d22f9-b7cf-4ff8-9513-571a2701ec08@github.com>

On Sat, 19 Feb 2022 10:15:15 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> `dtraceAttacher.cpp` with all the relevant definitions was deleted [here](https://github.com/openjdk/jdk/commit/071bd521bca2485c6df95c45e4310d39b05bd046)
> in connection with [JDK-8244224](https://bugs.openjdk.java.net/browse/JDK-8244224) (Remove the Solaris and SPARC Ports).
> 
> I deleted `dtraceAttacher.cpp`, and the 4 include statements of it in 4 `src/hotspot/os/???/attachListener_???.cpp` files.
> 
> Ran tests, mostly to check that it still compiles on various platforms.

Looks like I mis-clicked and hit Comment instead of Approve! Oops.

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

PR: https://git.openjdk.java.net/jdk/pull/7544

From dholmes at openjdk.java.net  Tue Feb 22 12:26:52 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Feb 2022 12:26:52 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <A8KEg03nvghZ-WFGi41gJfE7cU85FxVY8Kiw7Gfw7YQ=.bd064695-e381-4933-a274-6e9751ea63c9@github.com>

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

Hi Daniel,

Hotspot changes look fine.

Some of the casts in other code look odd to me, but I'll leave that for the security-libs folk to comment on.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7565

From duke at openjdk.java.net  Tue Feb 22 13:29:23 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Tue, 22 Feb 2022 13:29:23 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v9]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <FRnWbfZ942TJSmg4GjQJnqUrYGg2iNlJh3JVG0d5Ie8=.a70966c6-e350-4d78-9995-863708ce650c@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: TestCase issues resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/f0e9d901..7b9069ce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=07-08

  Stats: 41 lines in 1 file changed: 0 ins; 17 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From djelinski at openjdk.java.net  Tue Feb 22 14:16:49 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 14:16:49 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
In-Reply-To: <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
Message-ID: <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>

On Tue, 22 Feb 2022 11:33:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> make/autoconf/flags-cflags.m4 line 136:
> 
>> 134:       CFLAGS_WARNINGS_ARE_ERRORS="-WX"
>> 135: 
>> 136:       WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"
> 
> This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK.

Done

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

PR: https://git.openjdk.java.net/jdk/pull/7565

From sjohanss at openjdk.java.net  Tue Feb 22 15:23:51 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 22 Feb 2022 15:23:51 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v9]
In-Reply-To: <FRnWbfZ942TJSmg4GjQJnqUrYGg2iNlJh3JVG0d5Ie8=.a70966c6-e350-4d78-9995-863708ce650c@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <FRnWbfZ942TJSmg4GjQJnqUrYGg2iNlJh3JVG0d5Ie8=.a70966c6-e350-4d78-9995-863708ce650c@github.com>
Message-ID: <TlhQzmirX_7r5fQrXEGp0t6YEkJYu8CQGMSbo4qWLC4=.5b2fe8bf-c762-41eb-8c17-96da31ca8f16@github.com>

On Tue, 22 Feb 2022 13:29:23 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: TestCase issues resolved.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 165:

> 163:                     System.out.println("TestCase Passed for pagesize: " + pageSize + ", allocated pagesize: " + size);
> 164:                     break;
> 165:                 }

The test is still failing for 16G pages: 

TestCase Passed for pagesize: 16G, allocated pagesize: 64K
----------System.err:(12/796)----------
java.lang.AssertionError: TestCase Failed for 16G page allocation, 
	at runtime.os.TestExplicitPageAllocation.testCase(TestExplicitPageAllocation.java:170)
	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:69)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:828)


The problem is that `requiredPageCount(i)` will return 0 for 16G pages because the heap is just 1G, so the test will fill in the `errorMessage` and then the test will continue. The test not breking after setting the `errorMessage` also looks a bit wrong. At least it made it a bit harder to spot the error.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From djelinski at openjdk.java.net  Tue Feb 22 16:43:28 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 16:43:28 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Move strictStrings to toolchain_cflags

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7565/files
  - new: https://git.openjdk.java.net/jdk/pull/7565/files/fe18b41d..0cfbb165

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7565&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7565&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7565

From ihse at openjdk.java.net  Tue Feb 22 16:43:30 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 16:43:30 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
 <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>
Message-ID: <Zs7aKh_SdESd32qIE2JRDRmbuEIfHnpvnbQ7OJZgyiE=.6b7f1d75-696d-440d-bfe3-0c49a4db8cc5@github.com>

On Tue, 22 Feb 2022 14:13:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 136:
>> 
>>> 134:       CFLAGS_WARNINGS_ARE_ERRORS="-WX"
>>> 135: 
>>> 136:       WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings"
>> 
>> This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK.
>
> Done

Did you forget to push the fix?

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

PR: https://git.openjdk.java.net/jdk/pull/7565

From djelinski at openjdk.java.net  Tue Feb 22 16:43:31 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Feb 2022 16:43:31 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <Zs7aKh_SdESd32qIE2JRDRmbuEIfHnpvnbQ7OJZgyiE=.6b7f1d75-696d-440d-bfe3-0c49a4db8cc5@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <MoekcL357tYhXlfgPgauOQJOeDz2FxFAsbYjLzwz9GQ=.ab84adac-b120-428b-9ac3-6bff9a5a07d6@github.com>
 <KAp5pF0bypySUh4oxcQGlc8eXcCwS03IMXw2dY74LmI=.5f03904b-9c83-4a5d-bc7d-f236dfb1c520@github.com>
 <Zs7aKh_SdESd32qIE2JRDRmbuEIfHnpvnbQ7OJZgyiE=.6b7f1d75-696d-440d-bfe3-0c49a4db8cc5@github.com>
Message-ID: <2SOr0Aam68G8M26cjL1kFsz9YEWRr2lNfIsu_9rq-i8=.94d1aba2-a323-4e2d-9916-253dce6c98e7@github.com>

On Tue, 22 Feb 2022 16:35:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Done
>
> Did you forget to push the fix?

Push works better when connected... this time it's pushed for real.

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

PR: https://git.openjdk.java.net/jdk/pull/7565

From ihse at openjdk.java.net  Tue Feb 22 17:16:51 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 22 Feb 2022 17:16:51 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
Message-ID: <eMkXSbGRNHp_sQ1TsvgmlRGbI2YXvI74nE2HAFEqwrE=.b2d6048e-3557-4933-8302-bcb466ae6079@github.com>

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move strictStrings to toolchain_cflags

Now the build changes look good. Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7565

From dholmes at openjdk.java.net  Wed Feb 23 02:28:27 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Feb 2022 02:28:27 GMT
Subject: RFR: 8255577: Possible issues with SR_initialize
Message-ID: <O3nzeirRACNLQUXxZBqMX59xla27ufi64w_DK2Fd_sI=.64109628-6a55-4d16-83d1-9244053b1795@github.com>

Please review this trivial change that:

1. Removed dead code in relation to SR_sigset (unused since JDK 6)
2. Modified a vague comment to be slightly less vague.
3. Correct the copyright header which had been broken first in 2021 then again in 2022.

Testing: local test build.

Thanks,
David

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

Commit messages:
 - 8255577: Possible issues with SR_initialize

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

PR: https://git.openjdk.java.net/jdk/pull/7584

From shade at openjdk.java.net  Wed Feb 23 07:45:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Feb 2022 07:45:49 GMT
Subject: RFR: 8255577: Possible issues with SR_initialize
In-Reply-To: <O3nzeirRACNLQUXxZBqMX59xla27ufi64w_DK2Fd_sI=.64109628-6a55-4d16-83d1-9244053b1795@github.com>
References: <O3nzeirRACNLQUXxZBqMX59xla27ufi64w_DK2Fd_sI=.64109628-6a55-4d16-83d1-9244053b1795@github.com>
Message-ID: <KOlCU5zYWLBIcbSTaw7F8QcYyASGznxMH9b_NbNFE-I=.af202fee-1ee9-40ce-8091-9352893475ba@github.com>

On Wed, 23 Feb 2022 02:20:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial change that:
> 
> 1. Removed dead code in relation to SR_sigset (unused since JDK 6)
> 2. Modified a vague comment to be slightly less vague.
> 3. Correct the copyright header which had been broken first in 2021 then again in 2022.
> 
> Testing: local test build.
> 
> Thanks,
> David

Looks fine and trivial.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7584

From duke at openjdk.java.net  Wed Feb 23 08:38:28 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Wed, 23 Feb 2022 08:38:28 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v10]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: TestCase issue resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/7b9069ce..f10b2d00

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=08-09

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From redestad at openjdk.java.net  Wed Feb 23 10:14:56 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 23 Feb 2022 10:14:56 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v10]
In-Reply-To: <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
Message-ID: <zjFXJ-_VYNUcbpxtnf6_FMdmMwXyA6Bwa-KJi6F5Wx8=.7ebc7cd3-5ef1-48f3-85d5-33a3bd552039@github.com>

On Wed, 23 Feb 2022 08:38:28 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: TestCase issue resolved.

@albertnetymk on the question whether a microbenchmark like this makes sense: I think it _can_ be useful to add micros that are diagnostics/verification tools for corner case effects, even if they'd be a bad fit for inclusion in automated regression testing. Still it's important to make sure each such micro has reasonable runtime, provides decent signal to noise and has well-documented external constraints. We do not automatically include newly added microbenchmarks in automated testing so don't worry about this clogging up the CI or weekly perf testing. 

Setting up benchmarks that stress large pages is brittle and depends a lot on the system and things out of control of the JMH micro itself, so I'd ask for a high-level comment in the microbenchmark that gives a quick rundown on what the benchmark is trying to test, how to configure the system, how you verify it's actually testing the right thing and in which configurations you expect to see an effect.

test/micro/org/openjdk/bench/vm/gc/MicroLargePages.java line 34:

> 32: public class MicroLargePages {
> 33: 
> 34:     @Param({"1073741824"})

Exactly 10^30 elements + array header size means the `long[]` will be a couple of bytes above 1GB. Have you tried the experiment on slightly smaller values?

To make the micro more practical in terms of runtime it'd be interesting if the effects can be verified using either smaller `ARRAYSIZE` by default, or by having the loop in `micro_HOP_DIST_4KB` that iterates from `0` to `ARRAYSIZE` only iterate a small fraction of the total size.

test/micro/org/openjdk/bench/vm/gc/MicroLargePages.java line 57:

> 55:     @Benchmark
> 56:     public void micro_HOP_DIST_4KB() {
> 57:         for (int i = 0; i < ITERS ; i++) {

JMH runs as many iterations it can in the allotted runtime. The `ITERS` loop here seem completely unnecessary and just increase the runtime of each 100x. Having a benchmark iteration take an excessively long time like this also throws off the total runtime estimates. 

If you want to make sure the micro runs for at least some number of times to capture some effect you'd be better off doing so by increasing the iteration time.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From sjohanss at openjdk.java.net  Wed Feb 23 10:23:58 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 23 Feb 2022 10:23:58 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v10]
In-Reply-To: <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
Message-ID: <cGlsVMZ9jRfZxoK2Ue0akyNLZ_5OL8yGN0vNlQ3ml3g=.785e5e6f-bbe2-44b9-a425-366d5dd82a0d@github.com>

On Wed, 23 Feb 2022 08:38:28 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: TestCase issue resolved.

Test is now working but I still have some additional comments.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 50:

> 48: 
> 49:     private static final String DIR_HUGE_PAGES = "/sys/kernel/mm/hugepages/";
> 50:     private static final long HEAP_SIZE_IN_KB = 1 * 1024 * 1024;

This heap size is used to calculate the required number of pages needed but it is not used when creating the process, so the calculation will be incorrect. I suggest you use this value in the process creation as well, to avoid accidentally change one value but not the other.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 70:

> 68:                 if (pageSizes[i]) {
> 69:                     testCase(i);
> 70:                     break;

Can you please motivate this break? Why do we only want to test the largest page size? And if this is the case why not just record the largest page size during the setup-phase?

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 93:

> 91:            return Long.toString(sizeInBytes / m) + "M";
> 92:         else
> 93:            return Long.toString(sizeInBytes / g) + "G";

Please add { } to the if-statements.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 171:

> 169:         if (errorMessage != "") {
> 170:             throw new AssertionError(errorMessage);
> 171:         }

So this now works, but I think it is pretty hard to follow the logic with the continues and breaks and I don't see any benefit from not just throwing the `AssertionError()` when a failure occurs. 

What do you think about something like this:

for (int i = index; i >= vmPageSizeIndex; i--) {
    if (pageSizes[i]) {
        String size = sizeFromIndex(i);
        System.out.println("Checking allocation for " + size);
        if (checkOutput(output, size)) {
            System.out.println("TestCase Passed for pagesize: " + pageSize + ", allocated pagesize: " + size);
            // Page allocation succeeded no need to check any more page sizes.
            return;
        } else {
            // Only consider this a test failure if there are enough configured
            // pages to allow this reservation to succeeded.
            if (requiredPageCount(i) <= pageCount[i]) {
                throw new AssertionError("TestCase Failed for " + size + " page allocation. " +
                                         "Required pages: " + requiredPageCount(i) + ", " +
                                         "Configured pages: " + pageCount[i]);
            }
        }
    }
}


I ran this through our testing and it also works.

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

Changes requested by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7326

From dholmes at openjdk.java.net  Wed Feb 23 11:05:50 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Feb 2022 11:05:50 GMT
Subject: RFR: 8255577: Possible issues with SR_initialize
In-Reply-To: <KOlCU5zYWLBIcbSTaw7F8QcYyASGznxMH9b_NbNFE-I=.af202fee-1ee9-40ce-8091-9352893475ba@github.com>
References: <O3nzeirRACNLQUXxZBqMX59xla27ufi64w_DK2Fd_sI=.64109628-6a55-4d16-83d1-9244053b1795@github.com>
 <KOlCU5zYWLBIcbSTaw7F8QcYyASGznxMH9b_NbNFE-I=.af202fee-1ee9-40ce-8091-9352893475ba@github.com>
Message-ID: <Kjtjuepy1nn2HzUfcse7hyIZRBK2YmeZT99l7AiawD0=.83c023b5-c106-4a9f-89b0-61e1aa3c36e6@github.com>

On Wed, 23 Feb 2022 07:42:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this trivial change that:
>> 
>> 1. Removed dead code in relation to SR_sigset (unused since JDK 6)
>> 2. Modified a vague comment to be slightly less vague.
>> 3. Correct the copyright header which had been broken first in 2021 then again in 2022.
>> 
>> Testing: local test build.
>> 
>> Thanks,
>> David
>
> Looks fine and trivial.

Thanks for the review @shipilev !

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

PR: https://git.openjdk.java.net/jdk/pull/7584

From stuefe at openjdk.java.net  Wed Feb 23 11:18:46 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 23 Feb 2022 11:18:46 GMT
Subject: RFR: 8255577: Possible issues with SR_initialize
In-Reply-To: <O3nzeirRACNLQUXxZBqMX59xla27ufi64w_DK2Fd_sI=.64109628-6a55-4d16-83d1-9244053b1795@github.com>
References: <O3nzeirRACNLQUXxZBqMX59xla27ufi64w_DK2Fd_sI=.64109628-6a55-4d16-83d1-9244053b1795@github.com>
Message-ID: <IHxpRVjcq6HBGehb-ePPuQriwTHb8KkLyRO8O18UgWU=.18de0ae0-3d71-4fe2-b2c7-159940f638fc@github.com>

On Wed, 23 Feb 2022 02:20:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial change that:
> 
> 1. Removed dead code in relation to SR_sigset (unused since JDK 6)
> 2. Modified a vague comment to be slightly less vague.
> 3. Correct the copyright header which had been broken first in 2021 then again in 2022.
> 
> Testing: local test build.
> 
> Thanks,
> David

Thanks for taking care of this!

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7584

From dholmes at openjdk.java.net  Wed Feb 23 11:36:50 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Feb 2022 11:36:50 GMT
Subject: RFR: 8255577: Possible issues with SR_initialize
In-Reply-To: <IHxpRVjcq6HBGehb-ePPuQriwTHb8KkLyRO8O18UgWU=.18de0ae0-3d71-4fe2-b2c7-159940f638fc@github.com>
References: <O3nzeirRACNLQUXxZBqMX59xla27ufi64w_DK2Fd_sI=.64109628-6a55-4d16-83d1-9244053b1795@github.com>
 <IHxpRVjcq6HBGehb-ePPuQriwTHb8KkLyRO8O18UgWU=.18de0ae0-3d71-4fe2-b2c7-159940f638fc@github.com>
Message-ID: <mfcsS25tN2Mb-3RRyD3O4pLjZh3qlZDPkO2Vjv2kTdo=.6b79878f-f69f-478a-ae0a-cbe9798300e4@github.com>

On Wed, 23 Feb 2022 11:15:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this trivial change that:
>> 
>> 1. Removed dead code in relation to SR_sigset (unused since JDK 6)
>> 2. Modified a vague comment to be slightly less vague.
>> 3. Correct the copyright header which had been broken first in 2021 then again in 2022.
>> 
>> Testing: local test build.
>> 
>> Thanks,
>> David
>
> Thanks for taking care of this!

Thanks for the review @tstuefe !

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

PR: https://git.openjdk.java.net/jdk/pull/7584

From dholmes at openjdk.java.net  Wed Feb 23 11:36:51 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Feb 2022 11:36:51 GMT
Subject: Integrated: 8255577: Possible issues with SR_initialize
In-Reply-To: <O3nzeirRACNLQUXxZBqMX59xla27ufi64w_DK2Fd_sI=.64109628-6a55-4d16-83d1-9244053b1795@github.com>
References: <O3nzeirRACNLQUXxZBqMX59xla27ufi64w_DK2Fd_sI=.64109628-6a55-4d16-83d1-9244053b1795@github.com>
Message-ID: <ffkU23VIoBjIviDUb3LU-f2ujyWBccXi25EV7Ehjqes=.36728385-cff2-4207-9a54-224281bf3ef6@github.com>

On Wed, 23 Feb 2022 02:20:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this trivial change that:
> 
> 1. Removed dead code in relation to SR_sigset (unused since JDK 6)
> 2. Modified a vague comment to be slightly less vague.
> 3. Correct the copyright header which had been broken first in 2021 then again in 2022.
> 
> Testing: local test build.
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: d017e988
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d017e988562999295315778e232d71e477afb407
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8255577: Possible issues with SR_initialize

Reviewed-by: shade, stuefe

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

PR: https://git.openjdk.java.net/jdk/pull/7584

From ayang at openjdk.java.net  Wed Feb 23 14:45:57 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 23 Feb 2022 14:45:57 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v10]
In-Reply-To: <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
Message-ID: <VbOAkxyLTn81Pza3mdhmuB5rOMGoOJ9FbhgV79g6jlU=.cabd04f9-c020-428c-8e66-39e1aaa9a8c2@github.com>

On Wed, 23 Feb 2022 08:38:28 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: TestCase issue resolved.

This PR has evolved quite much from what I reviewed/approved. I am dropping my approval now. Will re-review it later this week.

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From coleenp at openjdk.java.net  Wed Feb 23 16:56:20 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 23 Feb 2022 16:56:20 GMT
Subject: RFR: 8262400:
 runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails
 in test_ame5_compiled_vtable_stub with wrapper
Message-ID: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>

If the vtable stub function is deoptimized, it will get the error message from the interpreter, which doesn't include the receiver class.   Disable this class if DeoptimizeALot is passed in.

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

Commit messages:
 - 8262400: runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails in test_ame5_compiled_vtable_stub with wrapper

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

PR: https://git.openjdk.java.net/jdk/pull/7596

From dholmes at openjdk.java.net  Wed Feb 23 20:00:51 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Feb 2022 20:00:51 GMT
Subject: RFR: 8262400:
 runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails
 in test_ame5_compiled_vtable_stub with wrapper
In-Reply-To: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>
References: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>
Message-ID: <9SUsnSQmqBefhwBzgZ3I4vDIiZM3fnq1NHeUv71N-Yk=.dc0c1225-45d5-40db-87b7-0b9b35b2f88a@github.com>

On Wed, 23 Feb 2022 16:50:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> If the vtable stub function is deoptimized, it will get the error message from the interpreter, which doesn't include the receiver class.   Disable this class if DeoptimizeALot is passed in.

Hi Coleen,

As a test fix this seems fine. But is it worth trying to make the interpreter and compiler messages more alike?

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7596

From coleen.phillimore at oracle.com  Wed Feb 23 20:47:15 2022
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 23 Feb 2022 15:47:15 -0500
Subject: RFR: 8262400:
 runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails
 in test_ame5_compiled_vtable_stub with wrapper
In-Reply-To: <9SUsnSQmqBefhwBzgZ3I4vDIiZM3fnq1NHeUv71N-Yk=.dc0c1225-45d5-40db-87b7-0b9b35b2f88a@github.com>
References: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>
 <9SUsnSQmqBefhwBzgZ3I4vDIiZM3fnq1NHeUv71N-Yk=.dc0c1225-45d5-40db-87b7-0b9b35b2f88a@github.com>
Message-ID: <3dc5de25-eabf-26a3-bda8-b9752f14ab3f@oracle.com>



On 2/23/22 3:00 PM, David Holmes wrote:
> On Wed, 23 Feb 2022 16:50:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>
>> If the vtable stub function is deoptimized, it will get the error message from the interpreter, which doesn't include the receiver class.   Disable this class if DeoptimizeALot is passed in.
> Hi Coleen,
>
> As a test fix this seems fine. But is it worth trying to make the interpreter and compiler messages more alike?

I thought that would be a better fix, but unfortunately, this:

// This method is called from the "abstract_entry" of the interpreter.
// At that point, the arguments have already been removed from the stack
// and therefore we don't have the receiver object at our fingertips. 
(Though,
// on some platforms the receiver still resides in a register...). Thus,
// we have no choice but print an error message not containing the receiver
// type.
JRT_ENTRY(void, 
InterpreterRuntime::throw_AbstractMethodErrorWithMethod(JavaThread* current,
Method* missingMethod))
 ? ResourceMark rm(current);
 ? assert(missingMethod != NULL, "sanity");
 ? methodHandle m(current, missingMethod);
 ? LinkResolver::throw_abstract_method_error(m, THREAD);
JRT_END

Seems not practical.
Thanks for looking at this.
Coleen

>
> Thanks,
> David
>
> -------------
>
> Marked as reviewed by dholmes (Reviewer).
>
> PR: https://git.openjdk.java.net/jdk/pull/7596


From lmesnik at openjdk.java.net  Thu Feb 24 03:17:03 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 24 Feb 2022 03:17:03 GMT
Subject: RFR: 8262400:
 runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails
 in test_ame5_compiled_vtable_stub with wrapper
In-Reply-To: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>
References: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>
Message-ID: <bPaKNrmrW0VrnG7eVfcHQgwehYLeVrtyCjCJRWy8HXs=.98cb36c2-7348-444b-99c8-ed5985ff2d9f@github.com>

On Wed, 23 Feb 2022 16:50:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> If the vtable stub function is deoptimized, it will get the error message from the interpreter, which doesn't include the receiver class.   Disable this class if DeoptimizeALot is passed in.

Marked as reviewed by lmesnik (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7596

From mbaesken at openjdk.java.net  Thu Feb 24 12:36:31 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 24 Feb 2022 12:36:31 GMT
Subject: RFR: JDK-8282345: handle latest VS2022 in abstract_vm_version
Message-ID: <x-K1gKdLH1kwC__GnlxVDRzt_eFnCF6EU2TltRNAPuc=.4e076010-8c69-4d21-af5c-aed05e86892e@github.com>

Hi, please review this small VS-related change.
The latest VS2022 versions should be handled in abstract_vm_version, e.g. 17.0,  see
https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
Additionally, very old VS versions can be removed from abstract_vm_version.

Thanks, Matthias

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

Commit messages:
 - JDK-8282345

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

PR: https://git.openjdk.java.net/jdk/pull/7606

From coleenp at openjdk.java.net  Thu Feb 24 13:04:06 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 24 Feb 2022 13:04:06 GMT
Subject: RFR: 8262400:
 runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails
 in test_ame5_compiled_vtable_stub with wrapper
In-Reply-To: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>
References: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>
Message-ID: <mGyZLbGw1eAQMlXgC9JiP2vj8YHFIWsqs1kXySCAT_g=.b938bf9c-c7f1-4868-aeb5-9e570874ae32@github.com>

On Wed, 23 Feb 2022 16:50:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> If the vtable stub function is deoptimized, it will get the error message from the interpreter, which doesn't include the receiver class.   Disable this class if DeoptimizeALot is passed in.

Thanks Leonid!

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

PR: https://git.openjdk.java.net/jdk/pull/7596

From coleenp at openjdk.java.net  Thu Feb 24 13:04:06 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 24 Feb 2022 13:04:06 GMT
Subject: Integrated: 8262400:
 runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails
 in test_ame5_compiled_vtable_stub with wrapper
In-Reply-To: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>
References: <rT6ZbwEY5jl-fceTydQHoHltM_G428WiDPn07crk2FY=.0d213d14-c429-4d3a-a36a-44fb463566e8@github.com>
Message-ID: <GZTpSE92L6Y2V4O6dqz9sj8gNhS0D-iFr4jJFR9FCWQ=.23500eae-a588-43f1-b1ac-4808d495e099@github.com>

On Wed, 23 Feb 2022 16:50:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> If the vtable stub function is deoptimized, it will get the error message from the interpreter, which doesn't include the receiver class.   Disable this class if DeoptimizeALot is passed in.

This pull request has now been integrated.

Changeset: f4486a19
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f4486a190e38c57b7c10e6cff4622bd1b716a724
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8262400: runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails in test_ame5_compiled_vtable_stub with wrapper

Reviewed-by: dholmes, lmesnik

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

PR: https://git.openjdk.java.net/jdk/pull/7596

From weijun at openjdk.java.net  Thu Feb 24 17:51:07 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 24 Feb 2022 17:51:07 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
Message-ID: <xvKE6mKQqjoRcQ2vEzfSEZ9GAmuzYDaoSnkylfTno-c=.f32adddb-5b97-4f42-8c80-583db1f2cdd5@github.com>

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move strictStrings to toolchain_cflags

I'm the original author of `sspi.cpp`. All changes look fine to me. Thanks a lot for the enhancement.

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

PR: https://git.openjdk.java.net/jdk/pull/7565

From djelinski at openjdk.java.net  Thu Feb 24 17:56:05 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Feb 2022 17:56:05 GMT
Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build
 [v2]
In-Reply-To: <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
 <PUWdLWViZBlJloSWBNMj4Kw00kH5LEqHN4w_jBr12VM=.b45a326c-22ac-4fe2-a103-cd9f54e98033@github.com>
Message-ID: <dT9-STWdBmnXf6mFXNslesrmFvyLrLZMflRbNWjslIM=.a2d6dc98-41e4-4fce-a198-293bbb4ae650@github.com>

On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
>> 
>> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
>> 
>> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
>> 
>> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move strictStrings to toolchain_cflags

Great, thanks all for reviewing!

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

PR: https://git.openjdk.java.net/jdk/pull/7565

From djelinski at openjdk.java.net  Thu Feb 24 18:23:06 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Feb 2022 18:23:06 GMT
Subject: Integrated: 8281525: Enable Zc:strictStrings flag in Visual Studio
 build
In-Reply-To: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
References: <nDzZIsofyHzIoeQ90sQVv51SAHjLhmcjUenCxJWHf24=.1c031051-f320-4f68-872b-75581b2d8308@github.com>
Message-ID: <MF2IUkKV8ihC_zd8yRpJJPfPJ_Idc0_QU4crXs_1Zng=.fa781f16-8c29-4e73-9412-dfe7ec2e2aaa@github.com>

On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error.
> 
> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1).
> 
> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible.
> 
> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019.

This pull request has now been integrated.

Changeset: 23995f82
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/23995f822e540d799eb4bbc969229422257fbb08
Stats:     23 lines in 6 files changed: 0 ins; 0 del; 23 mod

8281525: Enable Zc:strictStrings flag in Visual Studio build

Reviewed-by: dholmes, ihse

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

PR: https://git.openjdk.java.net/jdk/pull/7565

From dholmes at openjdk.java.net  Thu Feb 24 23:03:13 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Feb 2022 23:03:13 GMT
Subject: RFR: JDK-8282345: handle latest VS2022 in abstract_vm_version
In-Reply-To: <x-K1gKdLH1kwC__GnlxVDRzt_eFnCF6EU2TltRNAPuc=.4e076010-8c69-4d21-af5c-aed05e86892e@github.com>
References: <x-K1gKdLH1kwC__GnlxVDRzt_eFnCF6EU2TltRNAPuc=.4e076010-8c69-4d21-af5c-aed05e86892e@github.com>
Message-ID: <belWTMvtnEhdPZ9S5pDrRZJpIsWajt0hpx4-OK5lkbQ=.f005d952-7fbc-44c7-882c-db29bd222210@github.com>

On Thu, 24 Feb 2022 12:30:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi, please review this small VS-related change.
> The latest VS2022 versions should be handled in abstract_vm_version, e.g. 17.0,  see
> https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> Additionally, very old VS versions can be removed from abstract_vm_version.
> 
> Thanks, Matthias

Looks fine. Removing the old versions is not necessary but probably not harmful either.

I wonder if MS will ever provide an actual version string for their compilers so we don't have to do this every time they get updated.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7606

From thomas.stuefe at gmail.com  Fri Feb 25 06:30:09 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 25 Feb 2022 07:30:09 +0100
Subject: Idea for making ResourceArea allocation signal safe
Message-ID: <CAA-vtUyDFJxh2EVmtCaYdhdTus4ZueNY=rR-jFnsHkZE3mFbKg@mail.gmail.com>

Hi,

I wanted to run an idea by the group.

In the context of signal handlers, we may allocate RA memory. That is not
ideal but may happen. One example is error reporting - there is no
guarantee, even if we are careful, that some code down the stack may not
use RA. Another example is things like AsyncGetCallTrace, used in the async
profiler. I'm sure there may be more examples.

The problem is that if the signal interrupts the thread while it was
modifying the arena underlaying its RA, the arena is left in an
inconsistent state and subsequent allocations from it may malfunction. RA
allocation is not reentry-safe.

A very simple solution to this would be double buffering. We could hold,
per thread, a secondary resource area, to be used only in signal handling.
At the entrance of the hotspot 0signal handler (which everyone goes
through, even in chain scenarios like with AsyncGetCallTrace) we would
switch over to the secondary resource area, and switch back when leaving
the hotspot signal handler.

The question here is whether to create the secondary RA upfront, at Thread
creation time, or on-demand only. Since not every thread may enter signal
handling, and even if it does it may never allocate RA memory in signal
handlers.

1) If we create it at thread creation time, we pay a small overhead for the
allocation of the RA itself as well as for the first init chunk in its
arena. It is not much, about 1K on 64-bit platforms, but still.

2) If we create it on demand only, we cause allocations in the signal
handler. Arguably this may happen anyway if the Thread were to allocate RA
in the signal handler, and that allocation were to cause arena expansion.
But today its rare. (2) has two variants:
 a) unconditionally create the secondary RA upon first invocation of a
signal handler if it does not exist
 b) hide the on-demand creation under the Thread::resource_area()
accessor() (if _resource_area == NULL create resource area).

(1) is safe and simple, but atm would cost two mallocs and about 1K of
memory per thread

(2a) means we pay for the arena of threads that enter signal handling but
never would allocate RA while in signal handler. This may be almost every
Thread. It also means we are now guaranteed to always malloc at least once
in signal handling.

(2b) seems elegant - we only create the secondary RA if a thread actually
needs it - but this affects every RA allocation in- and outside signal
handling, we now have a NULL check everywhere in the
Thread::resource_area() accessor.

There may be some further changes we could do to mitigate the costs:

- In RA, delay the creation of the first chunk until the resource area is
actually needed
- Or, the other way around, embed the first chunk of a Thread's resource
area into the Thread structure itself. But this would increase the size of
Thread, and it is already a monster.

What do you think?

Cheers, Thomas

From stuefe at openjdk.java.net  Fri Feb 25 09:23:26 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Feb 2022 09:23:26 GMT
Subject: RFR: JDK-8282382: Report glibc malloc tunables in error reports
Message-ID: <WGywDRIrpqNiOQ1FgrH5JAodsZ-rRN-gZ1XL7zNV68I=.96399799-3321-4693-b4a6-cc29c746b6be@github.com>

On Linux/glibc platforms, the hs-err file should report the malloc tunables, or at least MALLOC_ARENA_MAX, since that one can have a significant effect on footprint or malloc contention for a VM.

This patch adds this printout as a one-liner into hs-err files and jcmd VM.info reports:

Process Memory:                                                                    
...
glibc malloc tunables: MALLOC_PERTURB_=40, MALLOC_ARENA_MAX=1
If the tunables are default, we print glibc malloc tunables: (default).

Thanks, Thomas

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

Commit messages:
 - report glibc malloc tunables

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

PR: https://git.openjdk.java.net/jdk/pull/7620

From mdoerr at openjdk.java.net  Fri Feb 25 11:07:07 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 25 Feb 2022 11:07:07 GMT
Subject: RFR: JDK-8282345: handle latest VS2022 in abstract_vm_version
In-Reply-To: <x-K1gKdLH1kwC__GnlxVDRzt_eFnCF6EU2TltRNAPuc=.4e076010-8c69-4d21-af5c-aed05e86892e@github.com>
References: <x-K1gKdLH1kwC__GnlxVDRzt_eFnCF6EU2TltRNAPuc=.4e076010-8c69-4d21-af5c-aed05e86892e@github.com>
Message-ID: <-neZuCU4QYiiuCTdSGmrK84EVe2UABFtBBrAiZNYs1A=.8f1154e4-b346-4f6a-8954-944381bae286@github.com>

On Thu, 24 Feb 2022 12:30:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi, please review this small VS-related change.
> The latest VS2022 versions should be handled in abstract_vm_version, e.g. 17.0,  see
> https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> Additionally, very old VS versions can be removed from abstract_vm_version.
> 
> Thanks, Matthias

+1
Visual Studio 2017 is the oldest supported version according to https://openjdk.java.net/groups/build/doc/building.html
So, should be fine to remove a couple of very old ones.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7606

From mbaesken at openjdk.java.net  Fri Feb 25 12:30:00 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 25 Feb 2022 12:30:00 GMT
Subject: RFR: JDK-8282345: handle latest VS2022 in abstract_vm_version
In-Reply-To: <x-K1gKdLH1kwC__GnlxVDRzt_eFnCF6EU2TltRNAPuc=.4e076010-8c69-4d21-af5c-aed05e86892e@github.com>
References: <x-K1gKdLH1kwC__GnlxVDRzt_eFnCF6EU2TltRNAPuc=.4e076010-8c69-4d21-af5c-aed05e86892e@github.com>
Message-ID: <JmanJkqvy0rIDbpcw11WFMOKZL9kpUCKrw9CopiDvuM=.dec9f4bd-6897-44be-b157-864af5ee7621@github.com>

On Thu, 24 Feb 2022 12:30:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi, please review this small VS-related change.
> The latest VS2022 versions should be handled in abstract_vm_version, e.g. 17.0,  see
> https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> Additionally, very old VS versions can be removed from abstract_vm_version.
> 
> Thanks, Matthias

Hi David and Martin, thanks for the reviews.
>Visual Studio 2017 is the oldest supported 
So we could probably also remove some old pre VS2015 workarounds if there are any left in the codebase.

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

PR: https://git.openjdk.java.net/jdk/pull/7606

From mbaesken at openjdk.java.net  Fri Feb 25 12:30:00 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 25 Feb 2022 12:30:00 GMT
Subject: Integrated: JDK-8282345: handle latest VS2022 in abstract_vm_version
In-Reply-To: <x-K1gKdLH1kwC__GnlxVDRzt_eFnCF6EU2TltRNAPuc=.4e076010-8c69-4d21-af5c-aed05e86892e@github.com>
References: <x-K1gKdLH1kwC__GnlxVDRzt_eFnCF6EU2TltRNAPuc=.4e076010-8c69-4d21-af5c-aed05e86892e@github.com>
Message-ID: <paWGj4HwzaJ9NkNy1LH21CtIk7YNH5-fcDdZweHPeok=.74c03cef-a85b-4a7c-a94d-f3d2b1b14194@github.com>

On Thu, 24 Feb 2022 12:30:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi, please review this small VS-related change.
> The latest VS2022 versions should be handled in abstract_vm_version, e.g. 17.0,  see
> https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
> Additionally, very old VS versions can be removed from abstract_vm_version.
> 
> Thanks, Matthias

This pull request has now been integrated.

Changeset: 735e86b0
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/735e86b0f71c97c2ba35c1cffd9b4492a8ca55bc
Stats:     10 lines in 1 file changed: 4 ins; 4 del; 2 mod

8282345: handle latest VS2022 in abstract_vm_version

Reviewed-by: dholmes, mdoerr

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

PR: https://git.openjdk.java.net/jdk/pull/7606

From ayang at openjdk.java.net  Fri Feb 25 13:09:56 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 25 Feb 2022 13:09:56 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <k-mqKdvjW5fsIuHomQYgxQI5KnSGtmO2CSFv-TYwbqY=.96384b92-a032-4293-9b38-11009709bdac@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
 <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
 <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>
 <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>
 <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@github.com>
 <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@github.com>
 <k-mqKdvjW5fsIuHomQYgxQI5KnSGtmO2CSFv-TYwbqY=.96384b92-a032-4293-9b38-11009709bdac@github.com>
Message-ID: <4jUo7n2RZpPa48GqECGWIKvia9v1nzo2mvUCtoMLcLY=.838dd8af-d0aa-4045-8cf6-38dd4a0562e0@github.com>

On Thu, 17 Feb 2022 15:50:05 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>>> > > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>>> > 
>>> > 
>>> > I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>>> 
>>> Thanks for digging out the JBS issue for this.
>>> 
>>> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>>> > 
>>> > 
>>> > I would actually like the following behavior:
>>> > ```
>>> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>>> > 
>>> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>>> > ```
>>> > 
>>> > 
>>> >     
>>> >       
>>> >     
>>> > 
>>> >       
>>> >     
>>> > 
>>> >     
>>> >   
>>> > I think this is close to what we do now.
>>> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>>> > ```
>>> > * a single 1G page and 256 2m pages for the heap
>>> > ```
>>> 
>>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
>>> 
>>> > ```
>>> > * 128 2m pages for the code cache
>>> >   ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>>> > ```
>>> > 
>>> > 
>>> >     
>>> >       
>>> >     
>>> > 
>>> >       
>>> >     
>>> > 
>>> >     
>>> >   
>>> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>>> 
>>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>>> 
>>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
>>> 
>>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
>> 
>> Hi @kstefanj , @tstuefe 
>> 
>> Thanks for sharing your views and comments. 
>> Please suggest what specific change you want us to do in the patch since it is fixing the already existing functionality.
>> 
>> Best Regards,
>> Swati
>
>> @swati-sha, I took a closer look at the test-case and right now it won't work when run on aarch64? On those systems in our test environment the base page size is 64k and the large page sizes are 2m and 512m. I took it for a spin to see what failures we would get and here it is:
>> 
>> ```
>> [0.001s][info][pagesize] LargePageSizeInBytes is not a valid large page size (1G) using the default large page size: 512M
>> [0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
>> [0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
>> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
>> [0.002s][info   ][pagesize] CodeHeap 'non-nmethods':  min=2496K max=5760K base=0x0000fffec55d0000 page_size=64K size=5760K
>> [0.002s][info   ][pagesize] CodeHeap 'profiled nmethods':  min=2496K max=120000K base=0x0000fffec5b70000 page_size=64K size=120000K
>> [0.002s][info   ][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K max=120000K base=0x0000fffecd0a0000 page_size=64K size=120000K
>> [0.002s][info   ][pagesize] Heap:  min=1G max=2G base=0x0000000080000000 page_size=64K size=2G
>> [0.002s][info   ][pagesize] Card Table:  min=4194305B max=4194305B base=0x0000fffee0db0000 page_size=64K size=4160K
>> [0.003s][info   ][pagesize] Mark Bitmap:  min=64M max=64M base=0x0000fffebc000000 page_size=64K size=64M
>> [0.003s][info   ][pagesize] Parallel Compact Data:  min=160K max=160K base=0x0000fffee08b0000 page_size=64K size=192K
>> [0.003s][info   ][pagesize] Parallel Compact Data:  min=4M max=4M base=0x0000fffee04b0000 page_size=64K size=4M
>> System does not support 1G pages
>> Number of 2M pages = 0
>> 
>> System does not support 1G pages
>> Number of reserved 1G pages = -1
>> 
>> Number of reserved 2M pages = 0
>> 
>> TestCase1 skipped
>> 
>> TestCase2 skipped
>> 
>> Exceptionjava.lang.RuntimeException: System property 'test.jdk' not set. This property is normally set by jtreg. When running test separately, set this property using '-Dtest.jdk=/path/to/jdk'.
>> TestCase4 skipped
>> 
>> ----------System.err:(11/560)----------
>> java.lang.AssertionError: Failed 4K page allocation
>> 
>> 	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:81)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>> 	at java.base/java.lang.Thread.run(Thread.java:828)
>> ```
>> 
>> So either we need to make the test more robust to also work without having hard coded page sizes but rather figure them out during the "setup" stage or we need to add a requires to avoid running on aarch64. I would prefer if the test was fixed to get more coverage and testing with different page sizes. Doing the requires could look something like:
>> 
>> ```
>> @requires os.arch=="amd64" | os.arch=="x86_64"
>> ```
> 
> Hi @kstefanj,
> 
> Added the generalized version of testcase. Please review and let me know.
> 
> Thanks,
> Swati

Hi @swati-sha, I have gone through the latest version. I think the change in hotspot is good enough, but the test still needs some improvement.

The test tries to be generic/general enough to cover many scenarios (diff combinations of archs, huge-page sizes, number of huge-page), which made the logic hard to follow. I believe debugging would be challenging as well when it fails. (At least the experience from @kstefanj corroborates my belief.)  Additionally, the Code Cache consumes large pages as well, so `-XX:ReservedCodeCacheSize=<> -XX:InitialCodeCacheSize=<>` should be in the command line to ensure there are enough large pages left for the Heap. (There are maybe other subtleties --- I didn't test much.)

Therefore, I would prefer sth like the following --- it's amd64 specific and focuses only on the fall-back behavior. (More test cases are probably interesting as well, but this captures exactly what's introduced in this PR.)


  var n_2m_pages = ...
  var n_1g_pages = ...
  
  if (n_1g_pages == 0 && n_2m_pages >= ...) {
    output = $(java <heap_size> <code_cache_size> -XX:-XX:LargePageSizeInBytes=1g --version)
    // checking output
  } else {
    // skip
    print "Skipping test because ..."
  }


Considering that having a reliably-working test in this particular case could be sutble and it's desirable to have this bugfix merged sooner, I suggest dropping the test and the microbenchmark (since there's some unresolved comment on it as well) from this PR and deal with that in another ticket/PR. What do others think?

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From hseigel at openjdk.java.net  Fri Feb 25 13:52:17 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 25 Feb 2022 13:52:17 GMT
Subject: RFR: 8282360: Merge POSIX implementations of ThreadCritical
Message-ID: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>

Please review this small change to merge the Posix (aix, bsd, linux) implementations of ThreadCritical into a single file named src/hotspot/os/posix/threadCritical_posix.cpp.  The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.

Thanks, Harold

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

Commit messages:
 - 8282360: Merge POSIX implementations of ThreadCritical

Changes: https://git.openjdk.java.net/jdk/pull/7622/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7622&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282360
  Stats: 125 lines in 3 files changed: 1 ins; 123 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7622.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7622/head:pull/7622

PR: https://git.openjdk.java.net/jdk/pull/7622

From zgu at openjdk.java.net  Fri Feb 25 14:09:01 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 25 Feb 2022 14:09:01 GMT
Subject: RFR: JDK-8282382: Report glibc malloc tunables in error reports
In-Reply-To: <WGywDRIrpqNiOQ1FgrH5JAodsZ-rRN-gZ1XL7zNV68I=.96399799-3321-4693-b4a6-cc29c746b6be@github.com>
References: <WGywDRIrpqNiOQ1FgrH5JAodsZ-rRN-gZ1XL7zNV68I=.96399799-3321-4693-b4a6-cc29c746b6be@github.com>
Message-ID: <YWIrhBZytLWefr_-oUZg4xdEyyY7mKsPYrLosZgR-Lc=.310ebe9f-4379-4cf5-841d-16a133cfb505@github.com>

On Fri, 25 Feb 2022 07:33:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> On Linux/glibc platforms, the hs-err file should report the malloc tunables, or at least MALLOC_ARENA_MAX, since that one can have a significant effect on footprint or malloc contention for a VM.
> 
> This patch adds this printout as a one-liner into hs-err files and jcmd VM.info reports:
> 
> 
> Process Memory:                                                                    
> ...
> glibc malloc tunables: MALLOC_PERTURB_=40, MALLOC_ARENA_MAX=1
> 
> 
> If the tunables are default, we print `glibc malloc tunables: (default)`.
> 
> 
> Thanks, Thomas

Just a minor suggestion. Otherwise, looks good.

src/hotspot/os/linux/os_linux.cpp line 2169:

> 2167: #endif // __GLIBC__
> 2168: 
> 2169: #ifdef __GLIBC__

You can merge these two `#ifdef __GLIBC__` blocks.

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7620

From stuefe at openjdk.java.net  Fri Feb 25 14:18:58 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Feb 2022 14:18:58 GMT
Subject: RFR: 8282360: Merge POSIX implementations of ThreadCritical
In-Reply-To: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
References: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
Message-ID: <v_1QcvxQJqwpKNi9-sYM6FTn-SoX8YK3yN0SdVS9KCk=.c041813a-7241-4229-9d32-73358d807428@github.com>

On Fri, 25 Feb 2022 13:44:06 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to merge the Posix (aix, bsd, linux) implementations of ThreadCritical into a single file named src/hotspot/os/posix/threadCritical_posix.cpp.  The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Looks good.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7622

From coleenp at openjdk.java.net  Fri Feb 25 15:05:52 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 25 Feb 2022 15:05:52 GMT
Subject: RFR: 8282360: Merge POSIX implementations of ThreadCritical
In-Reply-To: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
References: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
Message-ID: <CD3dDY-COYXH6zm4Q-_ZKsCXwtH7fm9zOJEUgvbUsO8=.78d21d47-2d13-4d37-bb99-6d4f6364454e@github.com>

On Fri, 25 Feb 2022 13:44:06 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to merge the Posix (aix, bsd, linux) implementations of ThreadCritical into a single file named src/hotspot/os/posix/threadCritical_posix.cpp.  The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Nice!

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7622

From stuefe at openjdk.java.net  Fri Feb 25 18:11:08 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Feb 2022 18:11:08 GMT
Subject: RFR: JDK-8282405: Make thread resource areas signal safe
Message-ID: <M1Kw_gUCjpqtZQw5VHRRQ_cBQbRNt4ekvBSnq-0krN0=.4272aea1-f51b-44dd-b828-b9d5a557f8b1@github.com>

In the context of signal handlers, we may allocate RA memory. That is not ideal but may happen. One example is error reporting - even if we are careful, some code down the stack may use RA. Another example is code running in the context of AsyncGetCallTrace. I'm sure there may be more examples.

The problem is that the signal may (rarely) leave the current thread's RA in an inconsistent state, especially if it got interrupted in the middle of a chunk turnover. Subsequent allocations from it inside the signal handler then would malfunction.

A simple solution would be double buffering. Let each thread have a second resource area, to be used only in signal handling. At the entrance of the hotspot signal handler (which everyone goes through, even in chain scenarios like with AsyncGetCallTrace) we would switch over to the secondary resource area, and switch back when leaving the hotspot signal handler.

Note that I proposed this on hs-runtime-dev [1] but I am actually not sure if the mailing lists work, since I did not see that mail delivered to subscribers. Therefore I went ahead and implemented a simple prototype. 

The prototype keeps matters simple:
- we just use two resource areas: the normal one and an alternate one for signal handling. So we don't handle recursive calls to signal handlers, see comment in signals_posix.cpp.
- we preallocate both resource area at thread creation time. For the pros and cons of pre-allocating them vs creating them on demand, and possible further improvements, pls see [1].

Tests:
- SAP nightlies in progress
- I try to come up with a test, but an automated regression test is not so easy. I tested this manually by corrupting the resource area of a thread, then faulting, and inside the signal handler, I was able to use the secondary resource area as expected. So I know it works.

[1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-February/054126.html

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

Commit messages:
 - double buffered resource areas

Changes: https://git.openjdk.java.net/jdk/pull/7624/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7624&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282405
  Stats: 78 lines in 4 files changed: 74 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7624.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7624/head:pull/7624

PR: https://git.openjdk.java.net/jdk/pull/7624

From stuefe at openjdk.java.net  Fri Feb 25 19:00:53 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Feb 2022 19:00:53 GMT
Subject: RFR: JDK-8282382: Report glibc malloc tunables in error reports
In-Reply-To: <WGywDRIrpqNiOQ1FgrH5JAodsZ-rRN-gZ1XL7zNV68I=.96399799-3321-4693-b4a6-cc29c746b6be@github.com>
References: <WGywDRIrpqNiOQ1FgrH5JAodsZ-rRN-gZ1XL7zNV68I=.96399799-3321-4693-b4a6-cc29c746b6be@github.com>
Message-ID: <jQs2cL73G_pLMpZeeznR1rlldnW1HHgHCinNrbuaL-U=.defd18be-a02c-453c-9a15-f904c70229ff@github.com>

On Fri, 25 Feb 2022 07:33:55 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> On Linux/glibc platforms, the hs-err file should report the malloc tunables, or at least MALLOC_ARENA_MAX, since that one can have a significant effect on footprint or malloc contention for a VM.
> 
> This patch adds this printout as a one-liner into hs-err files and jcmd VM.info reports:
> 
> 
> Process Memory:                                                                    
> ...
> glibc malloc tunables: MALLOC_PERTURB_=40, MALLOC_ARENA_MAX=1
> 
> 
> If the tunables are default, we print `glibc malloc tunables: (default)`.
> 
> 
> Thanks, Thomas

Thanks Zhengyu!

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

PR: https://git.openjdk.java.net/jdk/pull/7620

From stuefe at openjdk.java.net  Fri Feb 25 19:00:53 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Feb 2022 19:00:53 GMT
Subject: RFR: JDK-8282382: Report glibc malloc tunables in error reports
In-Reply-To: <YWIrhBZytLWefr_-oUZg4xdEyyY7mKsPYrLosZgR-Lc=.310ebe9f-4379-4cf5-841d-16a133cfb505@github.com>
References: <WGywDRIrpqNiOQ1FgrH5JAodsZ-rRN-gZ1XL7zNV68I=.96399799-3321-4693-b4a6-cc29c746b6be@github.com>
 <YWIrhBZytLWefr_-oUZg4xdEyyY7mKsPYrLosZgR-Lc=.310ebe9f-4379-4cf5-841d-16a133cfb505@github.com>
Message-ID: <U1KdrTOn27hYxO8UFW4CSZsML83Mcrq0hhgrSlpJJM8=.f43cda4b-23e2-4bcb-bb0a-bf1198f6325b@github.com>

On Fri, 25 Feb 2022 14:05:03 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> On Linux/glibc platforms, the hs-err file should report the malloc tunables, or at least MALLOC_ARENA_MAX, since that one can have a significant effect on footprint or malloc contention for a VM.
>> 
>> This patch adds this printout as a one-liner into hs-err files and jcmd VM.info reports:
>> 
>> 
>> Process Memory:                                                                    
>> ...
>> glibc malloc tunables: MALLOC_PERTURB_=40, MALLOC_ARENA_MAX=1
>> 
>> 
>> If the tunables are default, we print `glibc malloc tunables: (default)`.
>> 
>> 
>> Thanks, Thomas
>
> src/hotspot/os/linux/os_linux.cpp line 2169:
> 
>> 2167: #endif // __GLIBC__
>> 2168: 
>> 2169: #ifdef __GLIBC__
> 
> You can merge these two `#ifdef __GLIBC__` blocks.

Will do.

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

PR: https://git.openjdk.java.net/jdk/pull/7620

From dholmes at openjdk.java.net  Sat Feb 26 12:47:47 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 26 Feb 2022 12:47:47 GMT
Subject: RFR: 8282360: Merge POSIX implementations of ThreadCritical
In-Reply-To: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
References: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
Message-ID: <A3ot6HDz7WA81G8OYYRokMqEtqT15vJBu-7pkBj0z08=.93f14c62-b1f4-42f4-96cb-f79520ee7247@github.com>

On Fri, 25 Feb 2022 13:44:06 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to merge the Posix (aix, bsd, linux) implementations of ThreadCritical into a single file named src/hotspot/os/posix/threadCritical_posix.cpp.  The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Hi Harold,

The merge looks good.

The pre-existing use of PTHREAD_MUTEX_INITIALIZER is potentially problematic on FreeBSD - see comments in os_posix.cpp for mutexAttr. But that is a separate problem.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7622

From dcubed at openjdk.java.net  Sun Feb 27 03:49:12 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 27 Feb 2022 03:49:12 GMT
Subject: Integrated: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java
Message-ID: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com>

A trivial fix to ProblemList jdk/jfr/jvm/TestWaste.java.

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

Commit messages:
 - 8282428: ProblemList jdk/jfr/jvm/TestWaste.java

Changes: https://git.openjdk.java.net/jdk/pull/7631/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7631&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282428
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7631.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7631/head:pull/7631

PR: https://git.openjdk.java.net/jdk/pull/7631

From mikael at openjdk.java.net  Sun Feb 27 03:49:12 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Sun, 27 Feb 2022 03:49:12 GMT
Subject: Integrated: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java
In-Reply-To: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com>
References: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com>
Message-ID: <DDX-ysdzNTrnTRc2EYd2tRfTT15ZFkt8gaeTqEBjxuc=.4ad3f86d-6626-4ce0-9e94-77b69351fb8a@github.com>

On Sun, 27 Feb 2022 03:37:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/jvm/TestWaste.java.

Marked as reviewed by mikael (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7631

From dcubed at openjdk.java.net  Sun Feb 27 03:49:13 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 27 Feb 2022 03:49:13 GMT
Subject: Integrated: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java
In-Reply-To: <DDX-ysdzNTrnTRc2EYd2tRfTT15ZFkt8gaeTqEBjxuc=.4ad3f86d-6626-4ce0-9e94-77b69351fb8a@github.com>
References: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com>
 <DDX-ysdzNTrnTRc2EYd2tRfTT15ZFkt8gaeTqEBjxuc=.4ad3f86d-6626-4ce0-9e94-77b69351fb8a@github.com>
Message-ID: <GCsTvsGmrLJcQ2mix9v97nEx2QpaIiSouHxD38Emano=.d4dc7f60-05a7-4006-ae3f-228c9d322198@github.com>

On Sun, 27 Feb 2022 03:42:50 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jfr/jvm/TestWaste.java.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the lightning fast review! Especially considering
that it's Saturday night...

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

PR: https://git.openjdk.java.net/jdk/pull/7631

From dcubed at openjdk.java.net  Sun Feb 27 03:49:14 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 27 Feb 2022 03:49:14 GMT
Subject: Integrated: 8282428: ProblemList jdk/jfr/jvm/TestWaste.java
In-Reply-To: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com>
References: <7GF1MYhwuXsUb_yA9oLK1HcATRe_3T5aQMC3_Z1NvbI=.d2ddd8b4-b9ca-4a70-9d54-860fd2b95580@github.com>
Message-ID: <VMZR-8-zR3Z3DoGcEvvvO12IiUi0_AAgUI94x10V8EI=.10b6e917-725f-4d97-b0b9-584bd33624a9@github.com>

On Sun, 27 Feb 2022 03:37:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/jvm/TestWaste.java.

This pull request has now been integrated.

Changeset: 630ad1ac
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/630ad1acb20abae8bde037b8d23dd2a14a70d732
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8282428: ProblemList jdk/jfr/jvm/TestWaste.java

Reviewed-by: mikael

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

PR: https://git.openjdk.java.net/jdk/pull/7631

From duke at openjdk.java.net  Mon Feb 28 13:08:35 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 28 Feb 2022 13:08:35 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <4jUo7n2RZpPa48GqECGWIKvia9v1nzo2mvUCtoMLcLY=.838dd8af-d0aa-4045-8cf6-38dd4a0562e0@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
 <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
 <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>
 <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>
 <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@github.com>
 <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@github.com>
 <k-mqKdvjW5fsIuHomQYgxQI5KnSGtmO2CSFv-TYwbqY=.96384b92-a032-4293-9b38-11009709bdac@github.com>
 <4jUo7n2RZpPa48GqECGWIKvia9v1nzo2mvU
 CtoMLcLY=.838dd8af-d0aa-4045-8cf6-38dd4a0562e0@github.com>
Message-ID: <6MhghRS8-9VQDRVVtluDRKO-d4f5dhgwUog3nVkNIOg=.11cc3a38-c023-433c-82a2-e1c24dad5db4@github.com>

On Fri, 25 Feb 2022 13:06:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> XX:ReservedCodeCacheSize=<> -XX:InitialCodeCacheSize=<>

Hi @albertnetymk , @kstefanj ,

I have pushed the changes as suggested by @kstefanj, Initial version created was having explicit predicate  conditions for each test case and was in line to what is being proposed by you.  To accommodate your comments I have modified the test to include explicit -XX:ReservedCodeCacheSize and considering it while computing the required page count.

With this we should be able extend the existing test case to cover all the comments instead of re-instantiating initial test case version.

Looking forward to your feedback and approval.

Thanks,
Swati Sharma

PS:  Following are  the performance numbers for modified JMH benchmark over 2S 40C Ice lake Server (Intel(R) Xeon(R) Platinum 8380)

2M pages
Benchmark                           (ARRAYSIZE)  (NUM)   Mode  Cnt        Score         Error    Units
MicroLargePages.micro_HOP_DIST_4KB      2097152      1  thrpt   10  2047721.586 ? 1100027.488  ops/min
MicroLargePages.micro_HOP_DIST_4KB      2097152      2  thrpt   10   741954.577 ?  174530.486  ops/min
MicroLargePages.micro_HOP_DIST_4KB      2097152      4  thrpt   10   330249.555 ?   31666.913  ops/min

4K pages
Benchmark                           (ARRAYSIZE)  (NUM)   Mode  Cnt        Score        Error    Units
MicroLargePages.micro_HOP_DIST_4KB      2097152      1  thrpt   10  1412321.440 ? 188738.874  ops/min
MicroLargePages.micro_HOP_DIST_4KB      2097152      2  thrpt   10   515607.542 ?   2258.591  ops/min
MicroLargePages.micro_HOP_DIST_4KB      2097152      4  thrpt   10   303250.463 ?   2862.549  ops/min

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

PR: https://git.openjdk.java.net/jdk/pull/7326

From duke at openjdk.java.net  Mon Feb 28 13:08:34 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 28 Feb 2022 13:08:34 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v11]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <nzDLimKvr9Tjn1UHGMbtASP8Fsdo74KgcnvhX-vQW0U=.ed09a922-1fd4-4d9c-9046-6b0f4ea3224b@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: Resolved the comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/f10b2d00..ea081a1b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=09-10

  Stats: 52 lines in 2 files changed: 20 ins; 15 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7326.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7326/head:pull/7326

PR: https://git.openjdk.java.net/jdk/pull/7326

From hseigel at openjdk.java.net  Mon Feb 28 13:22:50 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 28 Feb 2022 13:22:50 GMT
Subject: RFR: 8282360: Merge POSIX implementations of ThreadCritical
In-Reply-To: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
References: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
Message-ID: <TMV2E4T2ExwAWDmgxOwToodKqK60ApFvnSMFFLhJRic=.4abb6b38-bb75-4100-96de-259c8baa072a@github.com>

On Fri, 25 Feb 2022 13:44:06 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to merge the Posix (aix, bsd, linux) implementations of ThreadCritical into a single file named src/hotspot/os/posix/threadCritical_posix.cpp.  The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Thanks Thomas, Coleen, and David for the reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/7622

From hseigel at openjdk.java.net  Mon Feb 28 13:22:51 2022
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 28 Feb 2022 13:22:51 GMT
Subject: Integrated: 8282360: Merge POSIX implementations of ThreadCritical
In-Reply-To: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
References: <i_kGFPI1j8vbF1_Zd71mCi36ZqEfVBitRRs_66wyltQ=.75e25940-8fe6-4fcf-ba84-6cf424146e31@github.com>
Message-ID: <I6f1oMVYwINuYNeLHuQ9lTLuYum-onfyjBdavQltuNk=.25a22438-ca2b-40c2-b3b6-5bf4ee2e8741@github.com>

On Fri, 25 Feb 2022 13:44:06 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to merge the Posix (aix, bsd, linux) implementations of ThreadCritical into a single file named src/hotspot/os/posix/threadCritical_posix.cpp.  The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: c58f5c67
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c58f5c67d1720d310c720667f7bf7486740c21c1
Stats:     125 lines in 3 files changed: 1 ins; 123 del; 1 mod

8282360: Merge POSIX implementations of ThreadCritical

Reviewed-by: stuefe, coleenp, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/7622

From dholmes at openjdk.java.net  Mon Feb 28 23:30:17 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 28 Feb 2022 23:30:17 GMT
Subject: RFR: 8281210: Add manpage changes for PAC-RET protection on
 Linux/AArch64
Message-ID: <kD7u2FoX1SbHvrd7p9L7zjRcp4G0YXSb4HELwcSs7tM=.05c14fe5-735c-4757-9615-bd4c5a5f1f53@github.com>

Please review this trivial update to apply the manpage changes from JDK-8277204. Those changes had to be applied to the closed markdown sources and then the regenerated output brought back into OpenJDK. There are some minor formatting changes to suit the prevailing style of the runtime flags section, and some incidental line break differences introduced by the pandoc tool.

Thanks,
David

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

Commit messages:
 - 8281210: Add manpage changes for PAC-RET protection on Linux/AArch64

Changes: https://git.openjdk.java.net/jdk/pull/7641/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7641&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281210
  Stats: 23 lines in 1 file changed: 7 ins; 2 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7641.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7641/head:pull/7641

PR: https://git.openjdk.java.net/jdk/pull/7641