From jwaters at openjdk.org  Tue Aug  1 05:58:51 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 1 Aug 2023 05:58:51 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
Message-ID: <_-f2Qyuw5hNzAgY00aVQLfJoHmS6oqFbBXeNmB1CK54=.df8cc296-bbe1-4d46-89d1-d149d9fb6d01@github.com>

On Fri, 28 Jul 2023 07:50:19 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Fix several formatting errors on Windows
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   zPhysicalMemoryBacking_windows.cpp

Reopening - To fix the errors that were deemed as needing a fix

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

PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1659616162

From stefank at openjdk.org  Tue Aug  1 06:57:52 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 1 Aug 2023 06:57:52 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
 <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
Message-ID: <lrd1AQwBka8rz9l5MgFwFh3oCG1EOgz9zHdcbVnz8RI=.cfeea78b-5148-4469-be1a-eed2842ad26b@github.com>

On Fri, 28 Jul 2023 09:16:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   zPhysicalMemoryBacking_windows.cpp
>
> src/hotspot/os/windows/gc/x/xMapper_windows.cpp line 253:
> 
>> 251: 
>> 252:   if (!res) {
>> 253:     fatal("Failed to unreserve memory: " INTPTR_FORMAT " " SIZE_FORMAT "M (%ld)",
> 
> Here, and in many other places:
> 
> PTR_FORMAT -> INTPTR_FORMAT both macros are the same. 
> 
> We use PTR_FORMAT in many many places to print pointers. I prefer it to INTPTR_FORMAT, since it does not convey the assumption of a type. After all, the type does not matter: we just print the pointer as a raw hex value. Also, INTPTR suggests intptr_t which suggests signedness, which has no place here.
> 
> *If* we want to change this, we should first agree on the INTPTR_FORMAT vs PTR_FORMAT difference. And why we use intptr_t in many places that actually call for an uintptr_t.
> 
> But I would not change it. There is no need.

Yes. Please keep using PTR_FORMAT to print what's semantically a pointer in ZGC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1280183227

From kbarrett at openjdk.org  Tue Aug  1 13:19:53 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Aug 2023 13:19:53 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
Message-ID: <gjeGjGELgfwYRFoy35FhvlknO1dNHgcSbOLQXFq92Hg=.a9138df3-def9-4a68-a7d2-7fba36fa70d1@github.com>

On Fri, 28 Jul 2023 07:50:19 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Fix several formatting errors on Windows
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   zPhysicalMemoryBacking_windows.cpp

Most/all of the PTR_FORMAT => INTPTR_FORMAT changes should not be made.
Especially those where the argument is the result of a call to p2i.
The p2i thing plus the definition of PTR_FORMAT are a bit of a kludge
to work around the variations in the implementations of "%p", which is
what one might wish PTR_FORMAT was using.

I've not looked at the rest yet.  It would be easier to do so once the
PTR_FORMAT => INTPTR_FORMAT changes were removed.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15063#pullrequestreview-1556982044

From kbarrett at openjdk.org  Tue Aug  1 13:19:56 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Aug 2023 13:19:56 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
 <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
Message-ID: <ecpltUktHU-BDJNL8dLgceuMs9X5FLvpzMRA9yt_498=.db6f5b74-9a95-434f-84b6-bc376c573616@github.com>

On Fri, 28 Jul 2023 09:27:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   zPhysicalMemoryBacking_windows.cpp
>
> src/hotspot/os/windows/os_windows.cpp line 3382:
> 
>> 3380:     if (Verbose && PrintMiscellaneous) {
>> 3381:       reserveTimer.stop();
>> 3382:       tty->print_cr("reserve_memory of %zx bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes,
> 
> SIZE_FORMAT.

Regarding SIZE_FORMAT - https://bugs.openjdk.org/browse/JDK-8256379.  Some people have been replacing
uses of SIZE_FORMAT when touching the relevant code for other reasons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1280628344

From coleenp at openjdk.org  Tue Aug  1 16:31:49 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Aug 2023 16:31:49 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <ecpltUktHU-BDJNL8dLgceuMs9X5FLvpzMRA9yt_498=.db6f5b74-9a95-434f-84b6-bc376c573616@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
 <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
 <ecpltUktHU-BDJNL8dLgceuMs9X5FLvpzMRA9yt_498=.db6f5b74-9a95-434f-84b6-bc376c573616@github.com>
Message-ID: <HzLcls6nH9PYQ-4KfGQeprBdal-sHUGJlmIsoWDCqVk=.0b82685c-e0f2-48d1-8bc0-a2fee23d0df0@github.com>

On Tue, 1 Aug 2023 13:16:17 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 3382:
>> 
>>> 3380:     if (Verbose && PrintMiscellaneous) {
>>> 3381:       reserveTimer.stop();
>>> 3382:       tty->print_cr("reserve_memory of %zx bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes,
>> 
>> SIZE_FORMAT.
>
> Regarding SIZE_FORMAT - https://bugs.openjdk.org/browse/JDK-8256379.  Some people have been replacing
> uses of SIZE_FORMAT when touching the relevant code for other reasons.

Yes, I think it might be best if people started using %zd rather than adding new SIZE_FORMAT to the code. I haven't figured out the best way to change the rest.  If using %zx, I suggest adding 0x%zx.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1280885515

From thomas.stuefe at gmail.com  Tue Aug  1 17:01:36 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 1 Aug 2023 19:01:36 +0200
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <HzLcls6nH9PYQ-4KfGQeprBdal-sHUGJlmIsoWDCqVk=.0b82685c-e0f2-48d1-8bc0-a2fee23d0df0@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
 <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
 <ecpltUktHU-BDJNL8dLgceuMs9X5FLvpzMRA9yt_498=.db6f5b74-9a95-434f-84b6-bc376c573616@github.com>
 <HzLcls6nH9PYQ-4KfGQeprBdal-sHUGJlmIsoWDCqVk=.0b82685c-e0f2-48d1-8bc0-a2fee23d0df0@github.com>
Message-ID: <CAA-vtUzMPxYkhDHsWy6cX=hus=zA7Yk+Qc=WsV+8aZcj6FNtLQ@mail.gmail.com>

On Tue 1. Aug 2023 at 18:32, Coleen Phillimore <coleenp at openjdk.org> wrote:

> On Tue, 1 Aug 2023 13:16:17 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
>
> >> src/hotspot/os/windows/os_windows.cpp line 3382:
> >>
> >>> 3380:     if (Verbose && PrintMiscellaneous) {
> >>> 3381:       reserveTimer.stop();
> >>> 3382:       tty->print_cr("reserve_memory of %zx bytes took "
> JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes,
> >>
> >> SIZE_FORMAT.
> >
> > Regarding SIZE_FORMAT - https://bugs.openjdk.org/browse/JDK-8256379.
> Some people have been replacing
> > uses of SIZE_FORMAT when touching the relevant code for other reasons.
>
> Yes, I think it might be best if people started using %zd rather than
> adding new SIZE_FORMAT to the code. I haven't figured out the best way to
> change the rest.  If using %zx, I suggest adding 0x%zx.


Pity, I liked those macros. We also lose the ability to compile with older
compilers, e.g. vs2013.

But I really dislike wholesale replacements of X with X prime (newer,
shinier) for aesthetic reasons. I much rather have those replacements we
agree upon be done when code is touched for other reasons.  That causes
much less overhead for update maintainers.

-------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/15063#discussion_r1280885515
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/graal-dev/attachments/20230801/c0ddd12f/attachment.htm>

From coleenp at openjdk.org  Tue Aug  1 19:57:43 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Aug 2023 19:57:43 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code
Message-ID: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>

This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
Tested with tier1-4.

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

Commit messages:
 - unset Wconversion
 - Fix compactHashtable.cpp
 - Fix loaderConstraints.cpp, altHashing.cpp, classLoaderExt.cpp
 - Fix fieldLayoutBuilder.cpp by fixing Contended command line parameter.
 - Fix klassFactory.cpp
 - Fix systemDictionaryShared.cpp
 - Fix classLoader.cpp
 - Fix vmIntrinsics.cpp
 - Fix -Wconversion warnings in classfile code.

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

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

From coleenp at openjdk.org  Wed Aug  2 13:40:12 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Aug 2023 13:40:12 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
Message-ID: <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>

> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Missed a case that gets -Wconversion warning for ContendedPaddingWidth.  prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15111/files
  - new: https://git.openjdk.org/jdk/pull/15111/files/3fa12be0..0e97905c

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

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

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

From matsaave at openjdk.org  Wed Aug  2 19:02:57 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 2 Aug 2023 19:02:57 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
Message-ID: <B-fYAEvzsuYoiC1oWE7UZPILhIiaQZbOIA-5XMPm3ZY=.b08ec7f5-1e2c-4bbc-b19b-c9b360662dc4@github.com>

On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a case that gets -Wconversion warning for ContendedPaddingWidth.  prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max.

Thanks for this! I have a few questions and potential improvements overall this looks good!

src/hotspot/share/classfile/altHashing.cpp line 111:

> 109: }
> 110: 
> 111: static void halfsiphash_init32(uint32_t v[4], uint64_t seed) {

I believe all the bitwise operators here will promote the result to int. Will this cause further conversion issues with uint32_t?

src/hotspot/share/classfile/classFileParser.cpp line 5244:

> 5242:   // that changes, then InstanceKlass::idnum_can_increment()
> 5243:   // has to be changed accordingly.
> 5244:   ik->set_initial_method_idnum(checked_cast<u2>(ik->methods()->length()));

Here you are setting a field inside an instance klass to a field acquired from within the same instance klass. Maybe it would be better for this to be a method internal to InstanceKlass?

src/hotspot/share/classfile/symbolTable.cpp line 240:

> 238: 
> 239: double SymbolTable::get_load_factor() {
> 240:   return (double)_items_count/(double)_current_size;

Is this redundant? Both operands are `size_t` so you can cast the result as opposed to both operands.

src/hotspot/share/classfile/symbolTable.cpp line 926:

> 924:   if (_symbols_counted > 0) {
> 925:     tty->print_cr("  Percent removed          %3.2f",
> 926:           ((float)_symbols_removed / (float)_symbols_counted) * 100);

I think you can also just cast once here.

src/hotspot/share/classfile/symbolTable.cpp line 933:

> 931:   tty->print_cr("  Total symbol length      " SIZE_FORMAT_W(7), hi.total_length);
> 932:   tty->print_cr("  Maximum symbol length    " SIZE_FORMAT_W(7), hi.max_length);
> 933:   tty->print_cr("  Average symbol length    %7.2f", ((float)hi.total_length / (float)hi.total_count));

Same here

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

PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559621098
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282284397
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282289794
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282302648
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282303865
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282304084

From coleenp at openjdk.org  Wed Aug  2 19:25:42 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Aug 2023 19:25:42 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
Message-ID: <ohL1oGzD8XBLpi1scB1ffdEcQFXk22Oj1mGQyCNPZWM=.d9d8bbce-c4ea-457b-ba42-4f43dab430c7@github.com>

On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a case that gets -Wconversion warning for ContendedPaddingWidth.  prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max.

Thanks for looking at this in detail Matias and for asking questions.  I hope I've answered them sufficiently.

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

PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559677392

From coleenp at openjdk.org  Wed Aug  2 19:25:46 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Aug 2023 19:25:46 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <B-fYAEvzsuYoiC1oWE7UZPILhIiaQZbOIA-5XMPm3ZY=.b08ec7f5-1e2c-4bbc-b19b-c9b360662dc4@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
 <B-fYAEvzsuYoiC1oWE7UZPILhIiaQZbOIA-5XMPm3ZY=.b08ec7f5-1e2c-4bbc-b19b-c9b360662dc4@github.com>
Message-ID: <DZiNxgfxrYq-7FLiCLzVR7mV8NR4uETIxsySoAFf9JA=.0b38c143-342c-496c-85c2-bc230e62edbb@github.com>

On Wed, 2 Aug 2023 18:35:14 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed a case that gets -Wconversion warning for ContendedPaddingWidth.  prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max.
>
> src/hotspot/share/classfile/altHashing.cpp line 111:
> 
>> 109: }
>> 110: 
>> 111: static void halfsiphash_init32(uint32_t v[4], uint64_t seed) {
> 
> I believe all the bitwise operators here will promote the result to int. Will this cause further conversion issues with uint32_t?

Since uint32_t is wider, I don't think so (at least I don't get a warning for it with -Wconversion).

> src/hotspot/share/classfile/classFileParser.cpp line 5244:
> 
>> 5242:   // that changes, then InstanceKlass::idnum_can_increment()
>> 5243:   // has to be changed accordingly.
>> 5244:   ik->set_initial_method_idnum(checked_cast<u2>(ik->methods()->length()));
> 
> Here you are setting a field inside an instance klass to a field acquired from within the same instance klass. Maybe it would be better for this to be a method internal to InstanceKlass?

There are a few calls like this here, that should be in instanceKlass.  I'd rather not move it with this change.

> src/hotspot/share/classfile/symbolTable.cpp line 240:
> 
>> 238: 
>> 239: double SymbolTable::get_load_factor() {
>> 240:   return (double)_items_count/(double)_current_size;
> 
> Is this redundant? Both operands are `size_t` so you can cast the result as opposed to both operands.

If I cast the result, I'll lose the remainder.  I had to cast current_size because otherwise the compiler complained about it.

> src/hotspot/share/classfile/symbolTable.cpp line 933:
> 
>> 931:   tty->print_cr("  Total symbol length      " SIZE_FORMAT_W(7), hi.total_length);
>> 932:   tty->print_cr("  Maximum symbol length    " SIZE_FORMAT_W(7), hi.max_length);
>> 933:   tty->print_cr("  Average symbol length    %7.2f", ((float)hi.total_length / (float)hi.total_count));
> 
> Same here

I think each value needs to be cast to get the correct result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282319686
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282322968
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282321857
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282322221

From matsaave at openjdk.org  Wed Aug  2 19:51:42 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 2 Aug 2023 19:51:42 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
Message-ID: <PI3r8ExnRL0LPzaLUVMZGvAPg5duDkjTyc2ebtbvuNk=.b8a7b381-ccee-4eee-b0a7-c9c9e214d1e1@github.com>

On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a case that gets -Wconversion warning for ContendedPaddingWidth.  prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max.

Thank you for addressing my questions, it looks like everything is good then!

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559737926

From dholmes at openjdk.org  Wed Aug  2 23:29:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Aug 2023 23:29:00 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <DZiNxgfxrYq-7FLiCLzVR7mV8NR4uETIxsySoAFf9JA=.0b38c143-342c-496c-85c2-bc230e62edbb@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
 <B-fYAEvzsuYoiC1oWE7UZPILhIiaQZbOIA-5XMPm3ZY=.b08ec7f5-1e2c-4bbc-b19b-c9b360662dc4@github.com>
 <DZiNxgfxrYq-7FLiCLzVR7mV8NR4uETIxsySoAFf9JA=.0b38c143-342c-496c-85c2-bc230e62edbb@github.com>
Message-ID: <eTWyjd9woY9wqVS5gCn5WG0UdQ3Yr6UZbuyaYk4FFfI=.993f1011-2680-4f5b-b686-187577097665@github.com>

On Wed, 2 Aug 2023 19:18:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/symbolTable.cpp line 240:
>> 
>>> 238: 
>>> 239: double SymbolTable::get_load_factor() {
>>> 240:   return (double)_items_count/(double)_current_size;
>> 
>> Is this redundant? Both operands are `size_t` so you can cast the result as opposed to both operands.
>
> If I cast the result, I'll lose the remainder.  I had to cast current_size because otherwise the compiler complained about it.

Yep an unsigned 64-bit type can't be implicitly converted to double without risking a loss of value

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282500923

From dholmes at openjdk.org  Wed Aug  2 23:34:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Aug 2023 23:34:15 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <DZiNxgfxrYq-7FLiCLzVR7mV8NR4uETIxsySoAFf9JA=.0b38c143-342c-496c-85c2-bc230e62edbb@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
 <B-fYAEvzsuYoiC1oWE7UZPILhIiaQZbOIA-5XMPm3ZY=.b08ec7f5-1e2c-4bbc-b19b-c9b360662dc4@github.com>
 <DZiNxgfxrYq-7FLiCLzVR7mV8NR4uETIxsySoAFf9JA=.0b38c143-342c-496c-85c2-bc230e62edbb@github.com>
Message-ID: <KgJWMoAqDuzkZ1YQCad7O4RsLJopfXpS-LqQxUuOwD4=.e5db3002-10a6-4766-9819-7ca3f2a57591@github.com>

On Wed, 2 Aug 2023 19:19:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/symbolTable.cpp line 933:
>> 
>>> 931:   tty->print_cr("  Total symbol length      " SIZE_FORMAT_W(7), hi.total_length);
>>> 932:   tty->print_cr("  Maximum symbol length    " SIZE_FORMAT_W(7), hi.max_length);
>>> 933:   tty->print_cr("  Average symbol length    %7.2f", ((float)hi.total_length / (float)hi.total_count));
>> 
>> Same here
>
> I think each value needs to be cast to get the correct result.

Yes size_t values must be cast to float/double. Again I think double should be used here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282503088

From dholmes at openjdk.org  Wed Aug  2 23:34:11 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Aug 2023 23:34:11 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <B-fYAEvzsuYoiC1oWE7UZPILhIiaQZbOIA-5XMPm3ZY=.b08ec7f5-1e2c-4bbc-b19b-c9b360662dc4@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
 <B-fYAEvzsuYoiC1oWE7UZPILhIiaQZbOIA-5XMPm3ZY=.b08ec7f5-1e2c-4bbc-b19b-c9b360662dc4@github.com>
Message-ID: <luJwuMAq_2YRom90iwxouWvYtGHi_62san0i8YiSmP8=.9f838627-260a-42cd-b0e9-b547a9421757@github.com>

On Wed, 2 Aug 2023 18:57:46 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed a case that gets -Wconversion warning for ContendedPaddingWidth.  prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max.
>
> src/hotspot/share/classfile/symbolTable.cpp line 926:
> 
>> 924:   if (_symbols_counted > 0) {
>> 925:     tty->print_cr("  Percent removed          %3.2f",
>> 926:           ((float)_symbols_removed / (float)_symbols_counted) * 100);
> 
> I think you can also just cast once here.

These should probably be double rather than float - the float result will be promoted to double to be passed as an argument anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282502783

From dholmes at openjdk.org  Wed Aug  2 23:42:21 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Aug 2023 23:42:21 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
Message-ID: <dJ-yY3SyBvtP8J_IDzgXnOxSJqPz39QWAW_4yCVX73s=.3e9e5a50-8687-435a-bf1a-29b231624c47@github.com>

On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a case that gets -Wconversion warning for ContendedPaddingWidth.  prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max.

A couple of queries/comments but overall seems reasonable.

Thanbks.

src/hotspot/share/classfile/loaderConstraints.cpp line 498:

> 496:     for (int i = 0; i < len; i++) {
> 497:       LoaderConstraint* probe = set.constraint_at(i);
> 498:       sum += (int)sizeof(*probe) + (probe->num_loaders() * (int)sizeof(ClassLoaderData*));

Can't you just cast the final result to int?

src/hotspot/share/classfile/stringTable.cpp line 891:

> 889: 
> 890:   _shared_table.reset();
> 891:   CompactHashtableWriter writer((int)_items_count, ArchiveBuilder::string_stats());

This makes me question why `Items_count` Is a size_t, when we treat it as an int.

src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 59:

> 57:   if ((value % BytesPerLong) != 0) {
> 58:     JVMFlag::printError(verbose,
> 59:                         "ContendedPaddingWidth (%u) must be "

Why %u when it is an int?

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559971126
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282505262
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282505740
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282506266

From coleenp at openjdk.org  Thu Aug  3 00:16:06 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 00:16:06 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
Message-ID: <gEGn2o56tD2U4n80FOkS5zINWYVqELl9gjIKlMGVGK0=.2b9b98be-ebba-4c45-a0fb-3e5c2061fe90@github.com>

On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a case that gets -Wconversion warning for ContendedPaddingWidth.  prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max.

Thanks for reviewing, David.  Reran with -Wconversion and now tier1 on your suggestions.

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

PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559985858

From coleenp at openjdk.org  Thu Aug  3 00:16:11 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 00:16:11 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <dJ-yY3SyBvtP8J_IDzgXnOxSJqPz39QWAW_4yCVX73s=.3e9e5a50-8687-435a-bf1a-29b231624c47@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
 <dJ-yY3SyBvtP8J_IDzgXnOxSJqPz39QWAW_4yCVX73s=.3e9e5a50-8687-435a-bf1a-29b231624c47@github.com>
Message-ID: <81KnSfIwLtCaxX-0GqLcCMH2gBtq7ZmRHJz7RjOLpIE=.79851543-8c0c-48da-8f3d-cae1cdd612a0@github.com>

On Wed, 2 Aug 2023 23:36:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed a case that gets -Wconversion warning for ContendedPaddingWidth.  prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max.
>
> src/hotspot/share/classfile/loaderConstraints.cpp line 498:
> 
>> 496:     for (int i = 0; i < len; i++) {
>> 497:       LoaderConstraint* probe = set.constraint_at(i);
>> 498:       sum += (int)sizeof(*probe) + (probe->num_loaders() * (int)sizeof(ClassLoaderData*));
> 
> Can't you just cast the final result to int?

I suppose I could.

> src/hotspot/share/classfile/stringTable.cpp line 891:
> 
>> 889: 
>> 890:   _shared_table.reset();
>> 891:   CompactHashtableWriter writer((int)_items_count, ArchiveBuilder::string_stats());
> 
> This makes me question why `Items_count` Is a size_t, when we treat it as an int.

Good question. I see no reason why it needs to be.  Also _items_count in StringTable is the same.

> src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 59:
> 
>> 57:   if ((value % BytesPerLong) != 0) {
>> 58:     JVMFlag::printError(verbose,
>> 59:                         "ContendedPaddingWidth (%u) must be "
> 
> Why %u when it is an int?

I had a temporary version where it was uint that didn't do the range check message correctly.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282515731
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282517308
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282517830

From coleenp at openjdk.org  Thu Aug  3 00:16:12 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 00:16:12 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <luJwuMAq_2YRom90iwxouWvYtGHi_62san0i8YiSmP8=.9f838627-260a-42cd-b0e9-b547a9421757@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
 <B-fYAEvzsuYoiC1oWE7UZPILhIiaQZbOIA-5XMPm3ZY=.b08ec7f5-1e2c-4bbc-b19b-c9b360662dc4@github.com>
 <luJwuMAq_2YRom90iwxouWvYtGHi_62san0i8YiSmP8=.9f838627-260a-42cd-b0e9-b547a9421757@github.com>
Message-ID: <qAU0VmqLyp5B25WMbRTnL1CaZpMUYoGqEC3BAd-GMro=.ca08043c-b268-4d1c-abaa-cc2d141da986@github.com>

On Wed, 2 Aug 2023 23:30:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/classfile/symbolTable.cpp line 926:
>> 
>>> 924:   if (_symbols_counted > 0) {
>>> 925:     tty->print_cr("  Percent removed          %3.2f",
>>> 926:           ((float)_symbols_removed / (float)_symbols_counted) * 100);
>> 
>> I think you can also just cast once here.
>
> These should probably be double rather than float - the float result will be promoted to double to be passed as an argument anyway.

Changed to double.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282517473

From coleenp at openjdk.org  Thu Aug  3 00:16:13 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 00:16:13 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2]
In-Reply-To: <KgJWMoAqDuzkZ1YQCad7O4RsLJopfXpS-LqQxUuOwD4=.e5db3002-10a6-4766-9819-7ca3f2a57591@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <pU0ET_pmGVuKE0Swd-Da23Rdpr1zHUpqAQSMK4fMJTY=.03e8b9fa-0a00-40ca-93b9-5e3a2fc9f362@github.com>
 <B-fYAEvzsuYoiC1oWE7UZPILhIiaQZbOIA-5XMPm3ZY=.b08ec7f5-1e2c-4bbc-b19b-c9b360662dc4@github.com>
 <DZiNxgfxrYq-7FLiCLzVR7mV8NR4uETIxsySoAFf9JA=.0b38c143-342c-496c-85c2-bc230e62edbb@github.com>
 <KgJWMoAqDuzkZ1YQCad7O4RsLJopfXpS-LqQxUuOwD4=.e5db3002-10a6-4766-9819-7ca3f2a57591@github.com>
Message-ID: <UB44-uJ4-7NReOSVAs_e0pL2TO0-aqoRSuTyPDed_nY=.31188893-4210-4381-bbcb-58019abfe6f9@github.com>

On Wed, 2 Aug 2023 23:31:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think each value needs to be cast to get the correct result.
>
> Yes size_t values must be cast to float/double. Again I think double should be used here.

Also changed to double.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282517582

From coleenp at openjdk.org  Thu Aug  3 00:16:05 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 00:16:05 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v3]
In-Reply-To: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
Message-ID: <jYYtKk6DQyM9A4zsbGtXg3LeNtjhEQV82BYpGQRTDK4=.e7125a8a-2034-4275-b00d-3e64f1946cb8@github.com>

> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  David's suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15111/files
  - new: https://git.openjdk.org/jdk/pull/15111/files/0e97905c..864a80f7

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

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

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

From coleenp at openjdk.org  Thu Aug  3 01:37:08 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 01:37:08 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
Message-ID: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>

> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix Atomic items_added code.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15111/files
  - new: https://git.openjdk.org/jdk/pull/15111/files/864a80f7..4019e4ed

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

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

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

From dholmes at openjdk.org  Thu Aug  3 06:45:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Aug 2023 06:45:33 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
Message-ID: <f-lt-Vow9qCBFU-JsbeJhNdfMAC3JYYJ5vcETlcPUUs=.fb243e38-386e-44e5-99fb-00d42163a62b@github.com>

On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Atomic items_added code.

Changes requested by dholmes (Reviewer).

src/hotspot/share/classfile/stringTable.cpp line 804:

> 802: void StringTable::allocate_shared_strings_array(TRAPS) {
> 803:   assert(DumpSharedSpaces, "must be");
> 804:   if (_items_count > max_jint) {

This is impossible given `_items_count_` is now an int

src/hotspot/share/classfile/symbolTable.cpp line 91:

> 89: 
> 90: static volatile int    _items_count = 0;
> 91: static volatile bool   _has_items_to_clean = false;

Nit: the extra spaces are not needed now we use a shorter type name

src/hotspot/share/classfile/symbolTable.cpp line 240:

> 238: 
> 239: double SymbolTable::get_load_factor() {
> 240:   return (double)_items_count/(double)_current_size;

You shouldn't need the cast to double now `_items_count` is an int.

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

PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1560333725
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282715657
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282717016
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282719265

From yzheng at openjdk.org  Thu Aug  3 06:57:52 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 3 Aug 2023 06:57:52 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers.
Message-ID: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>

This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.

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

Commit messages:
 - Allow jvmci compiler to query if an intrinsic is disabled by the HotSpot runtime.

Changes: https://git.openjdk.org/jdk/pull/15133/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15133&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313372
  Stats: 109 lines in 12 files changed: 93 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/15133.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15133/head:pull/15133

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

From yzheng at openjdk.org  Thu Aug  3 07:12:08 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 3 Aug 2023 07:12:08 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v2]
In-Reply-To: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
Message-ID: <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>

> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  update is_intrinsic_supported for _dcopySign,_fcopySign.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15133/files
  - new: https://git.openjdk.org/jdk/pull/15133/files/7328edcb..fba23164

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

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

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

From yzheng at openjdk.org  Thu Aug  3 07:12:31 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 3 Aug 2023 07:12:31 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v2]
In-Reply-To: <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
Message-ID: <iq5w7kT8631qt8NIlMpcB4LnTnn1YH3hCk4Kk0QcBc8=.f29c1ec8-3ea9-47cf-8af2-eda1f0aa85f3@github.com>

On Thu, 3 Aug 2023 07:12:08 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
>> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update is_intrinsic_supported for _dcopySign,_fcopySign.

src/hotspot/cpu/x86/vm_version_x86.cpp line 3229:

> 3227:   case vmIntrinsics::_electronicCodeBook_encryptAESCrypt:
> 3228:   case vmIntrinsics::_electronicCodeBook_decryptAESCrypt:
> 3229:   case vmIntrinsics::_galoisCounterMode_AESCrypt:

Stubs for these intrinsics are generated with the following CPU features.
See https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp#L159-L166

src/hotspot/cpu/x86/vm_version_x86.cpp line 3235:

> 3233:     break;
> 3234:   case vmIntrinsics::_bigIntegerRightShiftWorker:
> 3235:   case vmIntrinsics::_bigIntegerLeftShiftWorker:

See https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L4169-L4172

src/hotspot/cpu/x86/vm_version_x86.cpp line 3247:

> 3245:     break;
> 3246:   case vmIntrinsics::_dcopySign:
> 3247:   case vmIntrinsics::_fcopySign:

See https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/x86.ad#L1601-L1609

src/hotspot/cpu/x86/vm_version_x86.cpp line 3260:

> 3258:   case vmIntrinsics::_minF_strict:
> 3259:   case vmIntrinsics::_maxD_strict:
> 3260:   case vmIntrinsics::_minD_strict:

See https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/x86.ad#L1534-L1543

src/hotspot/cpu/x86/vm_version_x86.hpp line 689:

> 687:   static bool supports_avxonly()      { return ((supports_avx2() || supports_avx()) && !supports_evex()); }
> 688:   static bool supports_sha()          { return (_features & CPU_SHA) != 0; }
> 689:   static bool supports_fma()          { return (_features & CPU_FMA) != 0 && supports_avx(); }

https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/vm_version_x86.cpp#L1154-L1158
implies fma intrinsic can be used without AVX

src/hotspot/share/opto/c2compiler.cpp line 237:

> 235:   case vmIntrinsics::_electronicCodeBook_decryptAESCrypt:
> 236:     if (StubRoutines::electronicCodeBook_decryptAESCrypt() == nullptr) return false;
> 237:     break;

These two intrinsics were marked as supported on non-x86 platforms where the underlying stubs are not generated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282729047
PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282730887
PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282736834
PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282737285
PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282747067
PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282744793

From dnsimon at openjdk.org  Thu Aug  3 07:43:34 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 3 Aug 2023 07:43:34 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v2]
In-Reply-To: <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
Message-ID: <T8DcOwDNohxJKfwXGQHW42Mi6UUvd-kEIQ-r6u_V7KY=.abcfdb83-18d4-4b40-b803-c7a9863e9840@github.com>

On Thu, 3 Aug 2023 07:12:08 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
>> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update is_intrinsic_supported for _dcopySign,_fcopySign.

The JVMCI changes look good to me but someone else still needs to review the C1, C2 and shared assembler changes.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15133#pullrequestreview-1560433644

From dnsimon at openjdk.org  Thu Aug  3 08:34:49 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 3 Aug 2023 08:34:49 GMT
Subject: RFR: 8313421: [JVMCI] avoid locking class loader in
 CompilerToVM.lookupType
Message-ID: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>

This PR removes the need to lock the system class loader when converting Class instances for boot and platform classes to ResolvedJavaType objects. Not only is the system class loader a suboptimal loader for resolving these classes but locking it can cause deadlock in some JDK tests (e.g. `test/jdk/java/lang/System/LoggerFinder/`) when run with `-Xcomp`. For example, a thread that holds the system class loader lock and triggers a blocking compilation will deadlock with the compiler thread servicing the compilation if the compilation requires calling `CompilerToVM.lookupType` (which most compilations do).

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

Commit messages:
 - avoid locking class loader in CompilerToVM.lookupType (JDK-8313421)

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

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

From never at openjdk.org  Thu Aug  3 08:34:50 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 3 Aug 2023 08:34:50 GMT
Subject: RFR: 8313421: [JVMCI] avoid locking class loader in
 CompilerToVM.lookupType
In-Reply-To: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>
References: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>
Message-ID: <9XH2Qt_pWvg2D4UXp0Yg0DlhgA_l8tiL97Xj7A1RSpU=.8f52c42a-841a-4557-9c9b-9aabfd5ffc12@github.com>

On Wed, 2 Aug 2023 20:33:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR removes the need to lock the system class loader when converting Class instances for boot and platform classes to ResolvedJavaType objects. Not only is the system class loader a suboptimal loader for resolving these classes but locking it can cause deadlock in some JDK tests (e.g. `test/jdk/java/lang/System/LoggerFinder/`) when run with `-Xcomp`. For example, a thread that holds the system class loader lock and triggers a blocking compilation will deadlock with the compiler thread servicing the compilation if the compilation requires calling `CompilerToVM.lookupType` (which most compilations do).

This looks looks like a nice cleanup

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15128#pullrequestreview-1559962501

From dlong at openjdk.org  Thu Aug  3 10:30:36 2023
From: dlong at openjdk.org (Dean Long)
Date: Thu, 3 Aug 2023 10:30:36 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
Message-ID: <BLTrYPwloVxRrGVW-vvMq7b3u-y2oQu0iga0EiFqxIY=.9502a216-dab4-41d7-8824-4d284bc93d8d@github.com>

On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Atomic items_added code.

src/hotspot/cpu/x86/vm_version_x86.cpp line 1808:

> 1806: 
> 1807:   // Allocation prefetch settings
> 1808:   int cache_line_size = checked_cast<int>(prefetch_data_size());

I don't see why the old code would produce a warning, except with -Wsign-conversion on 32-bit platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283000602

From dlong at openjdk.org  Thu Aug  3 10:39:35 2023
From: dlong at openjdk.org (Dean Long)
Date: Thu, 3 Aug 2023 10:39:35 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
Message-ID: <6r732e6rR30hGvg1N4Ai3wxFqS_b2YBUl7R3k7QmiqA=.5731621e-9f0a-4888-bd90-cbdee8d2b0d9@github.com>

On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Atomic items_added code.

src/hotspot/share/classfile/classFileParser.cpp line 973:

> 971:   void remove_annotation(ID id) {
> 972:     assert((int)id >= 0 && (int)id < (int)_annotation_LIMIT, "oob");
> 973:     _annotations_present &= (int)~nth_bit((int)id);

This silences the warning but without a runtime check.  It would be nice to have a constexpr template version of nth_bit that return the desire type and also do a range check on the input, unlike this macro version always returns intx and returns 0 if the shift is out of range.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283009813

From dlong at openjdk.org  Thu Aug  3 10:55:37 2023
From: dlong at openjdk.org (Dean Long)
Date: Thu, 3 Aug 2023 10:55:37 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
Message-ID: <5is4L3oJSgutFejiS62EDxKd_l1KnRsgZgWJ25FkupA=.659ab838-bf6e-4f23-ab09-5e7a7f23b1ac@github.com>

On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Atomic items_added code.

src/hotspot/share/classfile/symbolTable.cpp line 90:

> 88: static size_t _current_size = 0;
> 89: 
> 90: static volatile int    _items_count = 0;

Shouldn't there be a check somewhere that this value doesn't overflow?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283026840

From dlong at openjdk.org  Thu Aug  3 11:00:36 2023
From: dlong at openjdk.org (Dean Long)
Date: Thu, 3 Aug 2023 11:00:36 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
Message-ID: <xX6Kd4eM0CQBOeaH0UQPt7HEqx78tmZkYfHvX23JxyA=.6c18d7f9-625d-4df9-8806-0621a2e38d2f@github.com>

On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Atomic items_added code.

src/hotspot/share/classfile/stringTable.cpp line 245:

> 243: 
> 244: void StringTable::item_added() {
> 245:   Atomic::inc(&_items_count);

Can this overflow?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283031367

From coleenp at openjdk.org  Thu Aug  3 12:01:35 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 12:01:35 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <f-lt-Vow9qCBFU-JsbeJhNdfMAC3JYYJ5vcETlcPUUs=.fb243e38-386e-44e5-99fb-00d42163a62b@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
 <f-lt-Vow9qCBFU-JsbeJhNdfMAC3JYYJ5vcETlcPUUs=.fb243e38-386e-44e5-99fb-00d42163a62b@github.com>
Message-ID: <0Pl5etzO5Rc2jTPuTmVEeBQ7A5PEpeAAYVqpvxm8brM=.bf79af3a-f91c-4238-9237-4302228a840f@github.com>

On Thu, 3 Aug 2023 06:37:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Atomic items_added code.
>
> src/hotspot/share/classfile/stringTable.cpp line 804:
> 
>> 802: void StringTable::allocate_shared_strings_array(TRAPS) {
>> 803:   assert(DumpSharedSpaces, "must be");
>> 804:   if (_items_count > max_jint) {
> 
> This is impossible given `_items_count_` is now an int

Maybe we still want items_count to be a size_t then so we can detect this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283099990

From coleenp at openjdk.org  Thu Aug  3 12:19:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 12:19:56 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v5]
In-Reply-To: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
Message-ID: <fkOZh7fIXC-O7CYX6RzWPx_h5GMZa4D5u67H_TNZAKc=.780b702c-4e6d-4c76-94ac-c8a841783d07@github.com>

> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Revert items_count change to int.  Add check for items_count overflow in SymbolTable.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15111/files
  - new: https://git.openjdk.org/jdk/pull/15111/files/4019e4ed..a092d427

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

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

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

From coleenp at openjdk.org  Thu Aug  3 12:19:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 12:19:57 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <f-lt-Vow9qCBFU-JsbeJhNdfMAC3JYYJ5vcETlcPUUs=.fb243e38-386e-44e5-99fb-00d42163a62b@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
 <f-lt-Vow9qCBFU-JsbeJhNdfMAC3JYYJ5vcETlcPUUs=.fb243e38-386e-44e5-99fb-00d42163a62b@github.com>
Message-ID: <YtWkcTdZ8FUfvCMzQTD7XbA7KLIcS4VsrpC-X53wg8s=.77b470f7-da2d-4d8c-9aa2-0507edf5a484@github.com>

On Thu, 3 Aug 2023 06:39:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Atomic items_added code.
>
> src/hotspot/share/classfile/symbolTable.cpp line 91:
> 
>> 89: 
>> 90: static volatile int    _items_count = 0;
>> 91: static volatile bool   _has_items_to_clean = false;
> 
> Nit: the extra spaces are not needed now we use a shorter type name

Since I'm reverting the change, it can have extra spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283110902

From coleenp at openjdk.org  Thu Aug  3 12:19:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 12:19:57 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <BLTrYPwloVxRrGVW-vvMq7b3u-y2oQu0iga0EiFqxIY=.9502a216-dab4-41d7-8824-4d284bc93d8d@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
 <BLTrYPwloVxRrGVW-vvMq7b3u-y2oQu0iga0EiFqxIY=.9502a216-dab4-41d7-8824-4d284bc93d8d@github.com>
Message-ID: <ujHEYqGzIRvryaI2GY-FqwZRxpgSTQfQpgwNWBTd7WY=.ff02193f-f547-49e2-8aee-5f62ec55c78f@github.com>

On Thu, 3 Aug 2023 10:27:57 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix Atomic items_added code.
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1808:
> 
>> 1806: 
>> 1807:   // Allocation prefetch settings
>> 1808:   int cache_line_size = checked_cast<int>(prefetch_data_size());
> 
> I don't see why the old code would produce a warning, except with -Wsign-conversion on 32-bit platforms.

I put the cast in because prefetch_data_size() returns uint and I'm narrowing it to int which has a lower positive range.  I assume checked_cast would find that.

> src/hotspot/share/classfile/classFileParser.cpp line 973:
> 
>> 971:   void remove_annotation(ID id) {
>> 972:     assert((int)id >= 0 && (int)id < (int)_annotation_LIMIT, "oob");
>> 973:     _annotations_present &= (int)~nth_bit((int)id);
> 
> This silences the warning but without a runtime check.  It would be nice to have a constexpr template version of nth_bit that return the desire type and also do a range check on the input, unlike this macro version always returns intx and returns 0 if the shift is out of range.

Let's fine a separate RFE for nth_bit and fix all of these at once.  This appears a lot.

> src/hotspot/share/classfile/stringTable.cpp line 245:
> 
>> 243: 
>> 244: void StringTable::item_added() {
>> 245:   Atomic::inc(&_items_count);
> 
> Can this overflow?

Yes, I'm going to revert the _items_count change.

> src/hotspot/share/classfile/symbolTable.cpp line 90:
> 
>> 88: static size_t _current_size = 0;
>> 89: 
>> 90: static volatile int    _items_count = 0;
> 
> Shouldn't there be a check somewhere that this value doesn't overflow?

Yes, there should be here too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283108957
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283109704
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283110162
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283113986

From coleenp at openjdk.org  Thu Aug  3 12:19:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 12:19:56 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
Message-ID: <2Nk0F_L4pfkDn4phbWydP66deZ2-yihLx_6cUYUnZgo=.abb90ce3-3932-455b-93e4-68799b638f6d@github.com>

On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Atomic items_added code.

I reverted the items_count change.

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

PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1560950292

From dlong at openjdk.org  Thu Aug  3 19:50:47 2023
From: dlong at openjdk.org (Dean Long)
Date: Thu, 3 Aug 2023 19:50:47 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <ujHEYqGzIRvryaI2GY-FqwZRxpgSTQfQpgwNWBTd7WY=.ff02193f-f547-49e2-8aee-5f62ec55c78f@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
 <BLTrYPwloVxRrGVW-vvMq7b3u-y2oQu0iga0EiFqxIY=.9502a216-dab4-41d7-8824-4d284bc93d8d@github.com>
 <ujHEYqGzIRvryaI2GY-FqwZRxpgSTQfQpgwNWBTd7WY=.ff02193f-f547-49e2-8aee-5f62ec55c78f@github.com>
Message-ID: <bAHprObz3g3apDNgT_CQbITg1mFTowRKasYQqYJUQVk=.2a657140-f9da-4485-aabe-8fe84a3ebd18@github.com>

On Thu, 3 Aug 2023 12:07:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.cpp line 1808:
>> 
>>> 1806: 
>>> 1807:   // Allocation prefetch settings
>>> 1808:   int cache_line_size = checked_cast<int>(prefetch_data_size());
>> 
>> I don't see why the old code would produce a warning, except with -Wsign-conversion on 32-bit platforms.
>
> I put the cast in because prefetch_data_size() returns uint and I'm narrowing it to int which has a lower positive range.  I assume checked_cast would find that.

OK, so you caught it by inspection and are fixing it proactively :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283649276

From coleenp at openjdk.org  Thu Aug  3 21:26:33 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Aug 2023 21:26:33 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4]
In-Reply-To: <bAHprObz3g3apDNgT_CQbITg1mFTowRKasYQqYJUQVk=.2a657140-f9da-4485-aabe-8fe84a3ebd18@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com>
 <BLTrYPwloVxRrGVW-vvMq7b3u-y2oQu0iga0EiFqxIY=.9502a216-dab4-41d7-8824-4d284bc93d8d@github.com>
 <ujHEYqGzIRvryaI2GY-FqwZRxpgSTQfQpgwNWBTd7WY=.ff02193f-f547-49e2-8aee-5f62ec55c78f@github.com>
 <bAHprObz3g3apDNgT_CQbITg1mFTowRKasYQqYJUQVk=.2a657140-f9da-4485-aabe-8fe84a3ebd18@github.com>
Message-ID: <YcakeVaaU6HW2AHAa1e6bz4dciJJOgTYIdWimX9Eyao=.e64afeb8-b473-49f0-a5d2-316e41ac5dbb@github.com>

On Thu, 3 Aug 2023 19:47:42 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I put the cast in because prefetch_data_size() returns uint and I'm narrowing it to int which has a lower positive range.  I assume checked_cast would find that.
>
> OK, so you caught it by inspection and are fixing it proactively :-)

Yeah heading off these -Wsign-conversion warnings :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283734384

From dholmes at openjdk.org  Fri Aug  4 05:21:35 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Aug 2023 05:21:35 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v5]
In-Reply-To: <fkOZh7fIXC-O7CYX6RzWPx_h5GMZa4D5u67H_TNZAKc=.780b702c-4e6d-4c76-94ac-c8a841783d07@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <fkOZh7fIXC-O7CYX6RzWPx_h5GMZa4D5u67H_TNZAKc=.780b702c-4e6d-4c76-94ac-c8a841783d07@github.com>
Message-ID: <E4VuWkXro4dQTML_OShQdh1DQHrYbvxFGJogU17Cf0Y=.ae7aa063-9be3-430f-84e3-eadd6d70cfc2@github.com>

On Thu, 3 Aug 2023 12:19:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert items_count change to int.  Add check for items_count overflow in SymbolTable.

Okay on reverting the `item_count` changes - but we should look at a follow up RFE to get these types sorted out.

Thanks

src/hotspot/share/classfile/stringTable.cpp line 805:

> 803:   assert(DumpSharedSpaces, "must be");
> 804:   if (_items_count > (size_t)max_jint) {
> 805:     fatal("Too many strings to be archived: " SIZE_FORMAT, _items_count);

An opportunity for `%zu`? :)

src/hotspot/share/classfile/stringTable.cpp line 828:

> 826:       // refer to more than 16384 * 16384 = 26M interned strings! Not a practical concern
> 827:       // but bail out for safety.
> 828:       log_error(cds)("Too many strings to be archived: " SIZE_FORMAT, _items_count);

Ditto `%zu`?

src/hotspot/share/classfile/symbolTable.cpp line 661:

> 659: size_t SymbolTable::estimate_size_for_archive() {
> 660:   if (_items_count > (size_t)max_jint) {
> 661:     fatal("Too many symbols to be archived: " SIZE_FORMAT, _items_count);

Ditto `%zu`?

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1562184513
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283988934
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283989728
PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283990078

From coleenp at openjdk.org  Fri Aug  4 13:34:34 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 4 Aug 2023 13:34:34 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v5]
In-Reply-To: <E4VuWkXro4dQTML_OShQdh1DQHrYbvxFGJogU17Cf0Y=.ae7aa063-9be3-430f-84e3-eadd6d70cfc2@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <fkOZh7fIXC-O7CYX6RzWPx_h5GMZa4D5u67H_TNZAKc=.780b702c-4e6d-4c76-94ac-c8a841783d07@github.com>
 <E4VuWkXro4dQTML_OShQdh1DQHrYbvxFGJogU17Cf0Y=.ae7aa063-9be3-430f-84e3-eadd6d70cfc2@github.com>
Message-ID: <1ETL8sKtJoR9kAD-YhnNP2Q7_aF0vZEbqZptm7F31N4=.a0064110-2e3f-47c2-b863-a12a8ad40e59@github.com>

On Fri, 4 Aug 2023 05:14:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert items_count change to int.  Add check for items_count overflow in SymbolTable.
>
> src/hotspot/share/classfile/stringTable.cpp line 805:
> 
>> 803:   assert(DumpSharedSpaces, "must be");
>> 804:   if (_items_count > (size_t)max_jint) {
>> 805:     fatal("Too many strings to be archived: " SIZE_FORMAT, _items_count);
> 
> An opportunity for `%zu`? :)

Ok, yes!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1284431061

From coleenp at openjdk.org  Fri Aug  4 13:56:58 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 4 Aug 2023 13:56:58 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v6]
In-Reply-To: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
Message-ID: <0_xD69hxE5gv5yV_rrwe-4BrcSq7s9yH3ylT5Rvbaag=.2b460632-c05c-4b35-bf2d-b55184dc3bcb@github.com>

> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add %zu

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15111/files
  - new: https://git.openjdk.org/jdk/pull/15111/files/a092d427..9cfa3f32

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

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

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

From coleenp at openjdk.org  Fri Aug  4 14:09:45 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 4 Aug 2023 14:09:45 GMT
Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v5]
In-Reply-To: <E4VuWkXro4dQTML_OShQdh1DQHrYbvxFGJogU17Cf0Y=.ae7aa063-9be3-430f-84e3-eadd6d70cfc2@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
 <fkOZh7fIXC-O7CYX6RzWPx_h5GMZa4D5u67H_TNZAKc=.780b702c-4e6d-4c76-94ac-c8a841783d07@github.com>
 <E4VuWkXro4dQTML_OShQdh1DQHrYbvxFGJogU17Cf0Y=.ae7aa063-9be3-430f-84e3-eadd6d70cfc2@github.com>
Message-ID: <sZur8uy7gz2CNRGFgbe5X1LUGCGZILD7BS5K9ygkktI=.961f4929-c230-48e5-80cc-282e53666db1@github.com>

On Fri, 4 Aug 2023 05:18:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay on reverting the item_count changes - but we should look at a follow up RFE to get these types sorted out.

In this case, I think we need items_count to be size_t so that we can do an explicit bounds check for CDS, so this type is correct.

Thanks for reviewing, Matias, Dean and David.

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

PR Comment: https://git.openjdk.org/jdk/pull/15111#issuecomment-1665665640

From coleenp at openjdk.org  Fri Aug  4 14:09:47 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 4 Aug 2023 14:09:47 GMT
Subject: Integrated: 8313564: Fix -Wconversion warnings in classfile code
In-Reply-To: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
References: <n-5ueaGrRVf8NukbHdlOQ_9uhz-OyDeDKHEIER4HDZg=.6d5677fb-fbc9-4e5b-9666-16e739dbbddc@github.com>
Message-ID: <2Pi0tWjOs5RTftP0IA2-VaSHw0RhAj3mjbbIMkCq5S8=.e1093551-c6fc-4990-a443-c2a9bd3c70be@github.com>

On Tue, 1 Aug 2023 19:50:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This patch fixes various -Wconversion warnings in classfile code.  I broke the change into commits so the changes are easier to see.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: f66cd500
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f66cd5008d155e52a20a351ecd10469286517bf4
Stats:     57 lines in 19 files changed: 5 ins; 0 del; 52 mod

8313564: Fix -Wconversion warnings in classfile code

Reviewed-by: matsaave, dholmes

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

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

From azafari at openjdk.org  Fri Aug  4 19:59:39 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 4 Aug 2023 19:59:39 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, 
 for globals.hpp
Message-ID: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>

The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.

### Tests
tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
tier1 all passed.

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

Commit messages:
 - Fixed intx->int for Wconversion warnings.

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

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

From dlong at openjdk.org  Fri Aug  4 22:50:33 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 4 Aug 2023 22:50:33 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>

On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

src/hotspot/share/opto/macro.cpp line 1841:

> 1839:       // Generate several prefetch instructions.
> 1840:       int step_size = AllocatePrefetchStepSize;
> 1841:       int distance = AllocatePrefetchDistance;

I think this is a step in the wrong direction.  Shouldn't these remain uint?

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

> 1256:           range(1, 64)                                                      \
> 1257:                                                                             \
> 1258:   product(int,  AllocatePrefetchStepSize, 16,                               \

I feel like uint is more correct for most of these.

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

> 1588:           "switch")                                                         \
> 1589:                                                                             \
> 1590:   develop(int, StopInterpreterAt, 0,                                        \

Some cpu ports access this from assembly, so changing the size is gong to require cpu-specific changes.  I'd rather see this and BytecodeCounter::_counter_value both changed to uint64_t.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1284893943
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1284894485
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1284893634

From dlong at openjdk.org  Fri Aug  4 22:54:30 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 4 Aug 2023 22:54:30 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <PRfp1ghIJhTXq2magc70d-HQ7ToZo0uX9BR59wiqtVA=.86d84d8b-5e9f-430a-b542-a4b934e5febc@github.com>

On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

I know HotSpot code is not very careful about distinguishing between int and uint, but shouldn't we prefer uint for values that can't be negative?  The disadvantage of uint though is will we get more -Wsign-conversion warnings to fix when that warning gets turned on.

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

PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1666252138

From coleenp at openjdk.org  Sat Aug  5 16:24:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 5 Aug 2023 16:24:28 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <OCoZEJurWns6Q3d17L0nJAT8tbq9pw4KviXcwXb4fec=.0c529184-3824-409a-8abb-754f9a037289@github.com>

On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

The argument checking code gives a nice error if you pass a negative value for a parameter in the range of 0 .. positive-number if the argument is an int, and a bad one if the argument is uint.  That's why in previous changes, I've preferred changing to int.  We could file an RFE to improve the error message though.  I don't know how hard that would be to fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1666545492

From coleenp at openjdk.org  Sat Aug  5 16:24:30 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 5 Aug 2023 16:24:30 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
Message-ID: <jn0WipGq3PQjZqzIpzytEkI3cEon2n2bxk8xTJX1VgE=.84daa763-cd40-4183-9839-f7ad91fbc633@github.com>

On Fri, 4 Aug 2023 22:44:49 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> src/hotspot/share/runtime/globals.hpp line 1590:
> 
>> 1588:           "switch")                                                         \
>> 1589:                                                                             \
>> 1590:   develop(int, StopInterpreterAt, 0,                                        \
> 
> Some cpu ports access this from assembly, so changing the size is gong to require cpu-specific changes.  I'd rather see this and BytecodeCounter::_counter_value both changed to uint64_t.

share/interpreter/bytecodeHistogram.cpp:int   BytecodeCounter::_counter_value = 0;

Maybe this should be inx instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285083024

From jwaters at openjdk.org  Mon Aug  7 02:29:31 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 7 Aug 2023 02:29:31 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
 <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
Message-ID: <9xaGezLeGvAidlgYkB0HaobJkvqbTi13FlUQT8H55Bg=.16175e10-1289-40e7-91cd-e73e89a739de@github.com>

On Fri, 28 Jul 2023 09:33:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   zPhysicalMemoryBacking_windows.cpp
>
> src/hotspot/share/code/codeHeapState.cpp line 1387:
> 
>> 1385:                     "      occupied space) is used by the blocks in the given size range.\n"
>> 1386:                     "      %ld characters are printed per percentage point.\n", pctFactor/100);
>> 1387:       ast->print_cr("total size   of all blocks: " INT64_FORMAT_W(7) "M", (total_size<<log2_seg_size)/M);
> 
> Wrong for 32-bit platforms.

I don't quite know what to do here, since on platforms where long < size_t (which in practice is probably just 32 bit or Windows) this division will promote to the type of size_t, which is likely 64 bits in size, but unfortunately %zd cannot be used here since the promotion only happens on said platforms where long < size_t, which will trip a compilation breaking warning on platforms where sizeof long is sizeof size_t, which is probably just 64 bit platforms that are not Windows

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1285324651

From dholmes at openjdk.org  Mon Aug  7 02:40:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Aug 2023 02:40:31 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <9jVcTomxlgxuotOMDSRY9JOkrKAQc4rFHbaG1ogMt8I=.f5761775-2196-4f20-a117-9fc4ed1c5894@github.com>

On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

I think the basic change from `intx` to `int` is sound - there is no reason for these flags to have a different size depending on the platform. But you need to check any other references to these flags (e.g. printing) are changed appropriately.

The issue of signed versus unsigned is a topic for a different day IMO.

Thanks.

src/hotspot/share/opto/macro.cpp line 1879:

> 1877:       // Generate several prefetch instructions.
> 1878:       int step_size = AllocatePrefetchStepSize;
> 1879:       int distance = AllocatePrefetchDistance;

Ditto no need to change

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

> 1102:           "Collect information about IndexSets")                            \
> 1103:                                                                             \
> 1104:   develop(int, FastAllocateSizeLimit, 128*K,                                \

Ensure the value is either never printed or else the format specifier is updated accordingly.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1564442865
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285309321
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285309479

From dholmes at openjdk.org  Mon Aug  7 02:40:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Aug 2023 02:40:33 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
Message-ID: <EnsYWEpCze7KmQZqH9-Zn7tUpqigBYv7mLgbk_qDt2Q=.d3f7ece3-0150-41e4-9a0f-9c6b6de80930@github.com>

On Fri, 4 Aug 2023 22:45:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> src/hotspot/share/opto/macro.cpp line 1841:
> 
>> 1839:       // Generate several prefetch instructions.
>> 1840:       int step_size = AllocatePrefetchStepSize;
>> 1841:       int distance = AllocatePrefetchDistance;
> 
> I think this is a step in the wrong direction.  Shouldn't these remain uint?

This change also doesn't fit the PR description. There is no need to change this in this PR (or even at all).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285309136

From dholmes at openjdk.org  Mon Aug  7 02:40:34 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Aug 2023 02:40:34 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <jn0WipGq3PQjZqzIpzytEkI3cEon2n2bxk8xTJX1VgE=.84daa763-cd40-4183-9839-f7ad91fbc633@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
 <jn0WipGq3PQjZqzIpzytEkI3cEon2n2bxk8xTJX1VgE=.84daa763-cd40-4183-9839-f7ad91fbc633@github.com>
Message-ID: <thTuLZnkW8d97JzhNjsA1gbjC52sF4FM_1TiVgvnC2U=.0937bb38-51c6-4ff7-951f-6ca5a7134793@github.com>

On Sat, 5 Aug 2023 16:21:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/globals.hpp line 1590:
>> 
>>> 1588:           "switch")                                                         \
>>> 1589:                                                                             \
>>> 1590:   develop(int, StopInterpreterAt, 0,                                        \
>> 
>> Some cpu ports access this from assembly, so changing the size is gong to require cpu-specific changes.  I'd rather see this and BytecodeCounter::_counter_value both changed to uint64_t.
>
> share/interpreter/bytecodeHistogram.cpp:int   BytecodeCounter::_counter_value = 0;
> 
> Maybe this should be inx instead.

The only reason to use `intx` is if this should be 32-bit on 32-bit and 64-bit on 64-bit. I don't think that is the case here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285312430

From dholmes at openjdk.org  Mon Aug  7 03:59:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Aug 2023 03:59:29 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <9xaGezLeGvAidlgYkB0HaobJkvqbTi13FlUQT8H55Bg=.16175e10-1289-40e7-91cd-e73e89a739de@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
 <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
 <9xaGezLeGvAidlgYkB0HaobJkvqbTi13FlUQT8H55Bg=.16175e10-1289-40e7-91cd-e73e89a739de@github.com>
Message-ID: <u3Mt_pPWyYY4nPNJKWhIyFJ9B3Qm5ox3UrKsBJ1eQLs=.382c083a-0af5-4a60-8f55-08e4daa1538c@github.com>

On Mon, 7 Aug 2023 02:27:07 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/share/code/codeHeapState.cpp line 1387:
>> 
>>> 1385:                     "      occupied space) is used by the blocks in the given size range.\n"
>>> 1386:                     "      %ld characters are printed per percentage point.\n", pctFactor/100);
>>> 1387:       ast->print_cr("total size   of all blocks: " INT64_FORMAT_W(7) "M", (total_size<<log2_seg_size)/M);
>> 
>> Wrong for 32-bit platforms.
>
> I don't quite know what to do here, since on platforms where long < size_t (which in practice is probably just 32 bit or Windows) this division will promote to the type of size_t, which is likely 64 bits in size, but unfortunately %zd cannot be used here since the promotion only happens on said platforms where long < size_t, which will trip a compilation breaking warning on platforms where sizeof long is sizeof size_t, which is probably just 64 bit platforms that are not Windows

If we defer the issue of what type `total_size` should be and just keep it as `unsigned long` then the simple and correct fix would be to use `%7lu` would it not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1285354581

From kbarrett at openjdk.org  Mon Aug  7 09:15:36 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 7 Aug 2023 09:15:36 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
 <tx_BHc4p7mMs0baqk3jllWOIrsvkpQTIWw_LBN2wNe8=.90ed8c3b-2bc4-46e0-9e4a-d7cbde9fed88@github.com>
Message-ID: <qETfI3fbhkZ8C37a8hk9TRAVM_N0AJGEaPDQl6U1A2I=.50148b54-74da-4aed-ae16-ac9e6f4c7a36@github.com>

On Fri, 28 Jul 2023 09:33:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   zPhysicalMemoryBacking_windows.cpp
>
> src/hotspot/share/code/codeHeapState.cpp line 1387:
> 
>> 1385:                     "      occupied space) is used by the blocks in the given size range.\n"
>> 1386:                     "      %ld characters are printed per percentage point.\n", pctFactor/100);
>> 1387:       ast->print_cr("total size   of all blocks: " INT64_FORMAT_W(7) "M", (total_size<<log2_seg_size)/M);
> 
> Wrong for 32-bit platforms.

We shouldn't defer the issue of what type `total_size` should be.  That's the underlying source of the problem.  Don't use `long` types in shared code!  I agree with @tstuefe  - these should be `size_t`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1285597007

From coleenp at openjdk.org  Mon Aug  7 12:05:34 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 7 Aug 2023 12:05:34 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <thTuLZnkW8d97JzhNjsA1gbjC52sF4FM_1TiVgvnC2U=.0937bb38-51c6-4ff7-951f-6ca5a7134793@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
 <jn0WipGq3PQjZqzIpzytEkI3cEon2n2bxk8xTJX1VgE=.84daa763-cd40-4183-9839-f7ad91fbc633@github.com>
 <thTuLZnkW8d97JzhNjsA1gbjC52sF4FM_1TiVgvnC2U=.0937bb38-51c6-4ff7-951f-6ca5a7134793@github.com>
Message-ID: <e9haO0Qu8ywQI39G0A87mXN60oyiKhvBoLW6lDy_W-w=.6b5f8228-95fd-432e-b5de-bf6130acbbaf@github.com>

On Mon, 7 Aug 2023 02:07:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> share/interpreter/bytecodeHistogram.cpp:int   BytecodeCounter::_counter_value = 0;
>> 
>> Maybe this should be inx instead.
>
> The only reason to use `intx` is if this should be 32-bit on 32-bit and 64-bit on 64-bit. I don't think that is the case here.

The reason that this should be reverted is that to fix it, you have to fix all the platform code and that seems out of scope for fixing Wconversion warnings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285771575

From coleenp at openjdk.org  Mon Aug  7 13:03:32 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 7 Aug 2023 13:03:32 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code
Message-ID: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>

Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.

src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
 1802 |     _thread->dec_held_monitor_count(rec + 1);
      |                                     ~~~~^~~

Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.

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

Commit messages:
 - Fix jvmci for held_monitor_count type.
 - Fix format strings for monitor_counts and fix arguments.cpp differently.
 - Fix gtests
 - Fix asserted files in runtime with one warning.
 - Fix signature.cpp
 - Fix continuationFreezeThaw.cpp
 - Fix deoptimization.cpp (size_of_frames is used to assign to _total_frame_sizes, which is an int and referred to from cpu code, so left it as an int and added checked cast instead)
 - Fixed synchronizer.cpp by fixing _held_monitor_count and _jni_monitor_count.
 - Fix arguments.cpp
 - Fixed sharedRuntime.cpp
 - ... and 3 more: https://git.openjdk.org/jdk/compare/0bb6af3b...4eeeb165

Changes: https://git.openjdk.org/jdk/pull/15177/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313882
  Stats: 115 lines in 24 files changed: 3 ins; 9 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/15177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177

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

From thartmann at openjdk.org  Mon Aug  7 13:21:31 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Aug 2023 13:21:31 GMT
Subject: RFR: 8313421: [JVMCI] avoid locking class loader in
 CompilerToVM.lookupType
In-Reply-To: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>
References: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>
Message-ID: <wtdhILJrjcWWV9rnXUoWL50jO3PuQxnXlrx-WqjWghY=.319ae0c7-004c-41ca-9276-8d9afa95e1ec@github.com>

On Wed, 2 Aug 2023 20:33:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR removes the need to lock the system class loader when converting Class instances for boot and platform classes to ResolvedJavaType objects. Not only is the system class loader a suboptimal loader for resolving these classes but locking it can cause deadlock in some JDK tests (e.g. `test/jdk/java/lang/System/LoggerFinder/`) when run with `-Xcomp`. For example, a thread that holds the system class loader lock and triggers a blocking compilation will deadlock with the compiler thread servicing the compilation if the compilation requires calling `CompilerToVM.lookupType` (which most compilations do).

Looks good to me but I'm not an expert in this code.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15128#pullrequestreview-1565314386

From coleenp at openjdk.org  Mon Aug  7 14:46:31 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 7 Aug 2023 14:46:31 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <e9haO0Qu8ywQI39G0A87mXN60oyiKhvBoLW6lDy_W-w=.6b5f8228-95fd-432e-b5de-bf6130acbbaf@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
 <jn0WipGq3PQjZqzIpzytEkI3cEon2n2bxk8xTJX1VgE=.84daa763-cd40-4183-9839-f7ad91fbc633@github.com>
 <thTuLZnkW8d97JzhNjsA1gbjC52sF4FM_1TiVgvnC2U=.0937bb38-51c6-4ff7-951f-6ca5a7134793@github.com>
 <e9haO0Qu8ywQI39G0A87mXN60oyiKhvBoLW6lDy_W-w=.6b5f8228-95fd-432e-b5de-bf6130acbbaf@github.com>
Message-ID: <qlMDwXhreLvHQcFBjGU4MCW4PnDzgGG35NLOYWVlQhQ=.6c08a83f-4218-4a10-a4df-47d7a286bbaf@github.com>

On Mon, 7 Aug 2023 12:02:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The only reason to use `intx` is if this should be 32-bit on 32-bit and 64-bit on 64-bit. I don't think that is the case here.
>
> The reason that this should be reverted is that to fix it, you have to fix all the platform code and that seems out of scope for fixing Wconversion warnings.

Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285976633

From coleenp at openjdk.org  Mon Aug  7 14:55:30 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 7 Aug 2023 14:55:30 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp
In-Reply-To: <qlMDwXhreLvHQcFBjGU4MCW4PnDzgGG35NLOYWVlQhQ=.6c08a83f-4218-4a10-a4df-47d7a286bbaf@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
 <jn0WipGq3PQjZqzIpzytEkI3cEon2n2bxk8xTJX1VgE=.84daa763-cd40-4183-9839-f7ad91fbc633@github.com>
 <thTuLZnkW8d97JzhNjsA1gbjC52sF4FM_1TiVgvnC2U=.0937bb38-51c6-4ff7-951f-6ca5a7134793@github.com>
 <e9haO0Qu8ywQI39G0A87mXN60oyiKhvBoLW6lDy_W-w=.6b5f8228-95fd-432e-b5de-bf6130acbbaf@github.com>
 <qlMDwXhreLvHQcFBjGU4MCW4PnDzgGG35NLOYWVlQhQ=.6c08a83f-4218-4a10-a4df-47d7a286bbaf@github.com>
Message-ID: <RjU1qMXK2exKM22cu9uTfO42ktOomR8C8eO_lHwWy8M=.74562de4-e5ac-454a-b090-913d54d28f88@github.com>

On Mon, 7 Aug 2023 14:43:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The reason that this should be reverted is that to fix it, you have to fix all the platform code and that seems out of scope for fixing Wconversion warnings.
>
> Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms.

This is complicated.  BytecodeCounter::_counter_value is an int, and StopInterpreterAt compares to that in shared code, which is fine because it'll promote the former to intx.  The cpu-specific code fetches the former as int and the latter as intx, except in one place so fixing either is going to be work.  The one place that complains on x86 is 

src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp:1865:12: warning: conversion from 'intx' {aka 'long int'} to 'int32_t' {aka 'int'} may change value [-Wconversion]
 1865 |            StopInterpreterAt,
      |            ^~~~~~~~~~~~~~~~~


  __ cmp32(ExternalAddress((address) &BytecodeCounter::_counter_value),
           StopInterpreterAt,
           rscratch1);

We could just static_cast StopInterpreterAt to int here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285995173

From azafari at openjdk.org  Tue Aug  8 09:22:12 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 8 Aug 2023 09:22:12 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v2]
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <wpSUjOXQqf9ob9r4uopTgdf3PgfH8psJ4TrcL7ndKxU=.53270424-974e-4245-8c57-faa78877dfe9@github.com>

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  Review comments applied.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15164/files
  - new: https://git.openjdk.org/jdk/pull/15164/files/18437bd0..1fe96046

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

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

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

From azafari at openjdk.org  Tue Aug  8 09:22:16 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 8 Aug 2023 09:22:16 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v2]
In-Reply-To: <EnsYWEpCze7KmQZqH9-Zn7tUpqigBYv7mLgbk_qDt2Q=.d3f7ece3-0150-41e4-9a0f-9c6b6de80930@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
 <EnsYWEpCze7KmQZqH9-Zn7tUpqigBYv7mLgbk_qDt2Q=.d3f7ece3-0150-41e4-9a0f-9c6b6de80930@github.com>
Message-ID: <TjxMidS07u17rRxABO1AhayMHx5rHpPUtVN64sEE0OY=.066a1599-242b-47de-923b-f7c0dc57dac3@github.com>

On Mon, 7 Aug 2023 02:01:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/opto/macro.cpp line 1841:
>> 
>>> 1839:       // Generate several prefetch instructions.
>>> 1840:       int step_size = AllocatePrefetchStepSize;
>>> 1841:       int distance = AllocatePrefetchDistance;
>> 
>> I think this is a step in the wrong direction.  Shouldn't these remain uint?
>
> This change also doesn't fit the PR description. There is no need to change this in this PR (or even at all).

Okay. Reverted back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1286844367

From azafari at openjdk.org  Tue Aug  8 09:22:18 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 8 Aug 2023 09:22:18 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v2]
In-Reply-To: <9jVcTomxlgxuotOMDSRY9JOkrKAQc4rFHbaG1ogMt8I=.f5761775-2196-4f20-a117-9fc4ed1c5894@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <9jVcTomxlgxuotOMDSRY9JOkrKAQc4rFHbaG1ogMt8I=.f5761775-2196-4f20-a117-9fc4ed1c5894@github.com>
Message-ID: <W2o79lMUv_DwgjJ79YBhaetP18Of1sp_psZZQpwfw-w=.fc84d959-b543-4623-8bff-140af6c59bad@github.com>

On Mon, 7 Aug 2023 02:01:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments applied.
>
> src/hotspot/share/opto/macro.cpp line 1879:
> 
>> 1877:       // Generate several prefetch instructions.
>> 1878:       int step_size = AllocatePrefetchStepSize;
>> 1879:       int distance = AllocatePrefetchDistance;
> 
> Ditto no need to change

Okay.
Reverted back.

> src/hotspot/share/runtime/globals.hpp line 1104:
> 
>> 1102:           "Collect information about IndexSets")                            \
>> 1103:                                                                             \
>> 1104:   develop(int, FastAllocateSizeLimit, 128*K,                                \
> 
> Ensure the value is either never printed or else the format specifier is updated accordingly.

Okay.
It is only printed in `[Global flags]` printing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1286844903
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1286842588

From coleenp at openjdk.org  Tue Aug  8 12:15:37 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Aug 2023 12:15:37 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v2]
In-Reply-To: <wpSUjOXQqf9ob9r4uopTgdf3PgfH8psJ4TrcL7ndKxU=.53270424-974e-4245-8c57-faa78877dfe9@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <wpSUjOXQqf9ob9r4uopTgdf3PgfH8psJ4TrcL7ndKxU=.53270424-974e-4245-8c57-faa78877dfe9@github.com>
Message-ID: <yeOyo39ml--m0vDZSBHWVznBvQ3UQWktNKQmY-XxY2g=.f65ca79b-5afb-4497-bc6b-332a6a8d7414@github.com>

On Tue, 8 Aug 2023 09:22:12 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments applied.

This looks good with the minor issue of removing a blank space.

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

> 1588:           "switch")                                                         \
> 1589:                                                                             \
> 1590:   develop(intx, StopInterpreterAt, 0,                                        \

Does this add a blank?  Should be aligned.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1567155588
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1287028124

From azafari at openjdk.org  Tue Aug  8 12:21:53 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 8 Aug 2023 12:21:53 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v3]
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <K798OIt0CzV1LKFjovZU-M6c160RfsurzFO4gMQRtZ8=.ebbe869c-bf1e-4dcd-a6e0-05dee3c70bba@github.com>

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  backslash aligned

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15164/files
  - new: https://git.openjdk.org/jdk/pull/15164/files/1fe96046..d88a1238

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

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

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

From dnsimon at openjdk.org  Tue Aug  8 13:54:53 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 8 Aug 2023 13:54:53 GMT
Subject: RFR: 8313421: [JVMCI] avoid locking class loader in
 CompilerToVM.lookupType [v2]
In-Reply-To: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>
References: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>
Message-ID: <5y-ZYjEZQrFUVuAvDQTWVGb4hOtBVzzpnWoKmK_-GAY=.a0c10c2e-3a7c-418f-a71c-ed86ecda7eaa@github.com>

> This PR removes the need to lock the system class loader when converting Class instances for boot and platform classes to ResolvedJavaType objects. Not only is the system class loader a suboptimal loader for resolving these classes but locking it can cause deadlock in some JDK tests (e.g. `test/jdk/java/lang/System/LoggerFinder/`) when run with `-Xcomp`. For example, a thread that holds the system class loader lock and triggers a blocking compilation will deadlock with the compiler thread servicing the compilation if the compilation requires calling `CompilerToVM.lookupType` (which most compilations do).

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

 - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8313421
 - avoid locking class loader in CompilerToVM.lookupType (JDK-8313421)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15128/files
  - new: https://git.openjdk.org/jdk/pull/15128/files/c32899db..86b6489a

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

  Stats: 17879 lines in 733 files changed: 8386 ins; 4137 del; 5356 mod
  Patch: https://git.openjdk.org/jdk/pull/15128.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15128/head:pull/15128

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

From coleenp at openjdk.org  Tue Aug  8 19:56:32 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Aug 2023 19:56:32 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v3]
In-Reply-To: <K798OIt0CzV1LKFjovZU-M6c160RfsurzFO4gMQRtZ8=.ebbe869c-bf1e-4dcd-a6e0-05dee3c70bba@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <K798OIt0CzV1LKFjovZU-M6c160RfsurzFO4gMQRtZ8=.ebbe869c-bf1e-4dcd-a6e0-05dee3c70bba@github.com>
Message-ID: <_CxHiiiT_x4tgRPapxwPdWdQWZcQ-3CATphJzpgf2VA=.1d2e1b54-4dcb-4a0b-ba9d-6fe08aed5d33@github.com>

On Tue, 8 Aug 2023 12:21:53 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   backslash aligned

Hi, I thought you were going to change this one too: LogEventsBufferEntries ?

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

PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1670221262

From coleenp at openjdk.org  Tue Aug  8 20:09:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 8 Aug 2023 20:09:56 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
Message-ID: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>

> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
> 
> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>       |                                     ~~~~^~~
> 
> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Make bytecode.hpp index() functions return u2 not long.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15177/files
  - new: https://git.openjdk.org/jdk/pull/15177/files/4eeeb165..a77884e4

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

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

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

From dlong at openjdk.org  Tue Aug  8 20:13:31 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 8 Aug 2023 20:13:31 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
Message-ID: <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com>

On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make bytecode.hpp index() functions return u2 not long.

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

> 1213:       }
> 1214:     }
> 1215:     c = getc(stream);

How about int c0 for the getc value, then the first line in the loop does
char c = checked_cast<char>(c0);
No other changes should be needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287641580

From dlong at openjdk.org  Tue Aug  8 21:12:32 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 8 Aug 2023 21:12:32 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
Message-ID: <yabO0a_IUVrINjWH29ARdKH1URnnrJZk-hJb1GU4dI4=.08134cee-265a-4070-bb32-670b06394cf0@github.com>

On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make bytecode.hpp index() functions return u2 not long.

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

> 1665: 
> 1666:     if (InitialHeapSize == 0) {
> 1667:       julong reasonable_initial = (julong)((phys_mem * (julong)InitialRAMPercentage) / 100);

This and the two changes above loses the fractional part.
Suggestion:

      julong reasonable_initial = (julong)((double)phys_mem * InitialRAMPercentage / 100.0);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287692376

From dlong at openjdk.org  Tue Aug  8 21:16:31 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 8 Aug 2023 21:16:31 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
Message-ID: <Y4acjWfP_gCHxeOUJZjhLd2f1DfrZO5sj2MWniyVqTc=.50a2c89e-d0ab-4371-bca2-10f9d022e9a1@github.com>

On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make bytecode.hpp index() functions return u2 not long.

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

> 2736:       }
> 2737: 
> 2738:       if (FLAG_SET_CMDLINE(MaxTenuringThreshold, (uint)max_tenuring_thresh) != JVMFlag::SUCCESS) {

MaxTenuringThreshold was recently changed to uint, so it would make sense change uintx above to uint.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287695274

From dlong at openjdk.org  Tue Aug  8 21:31:34 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 8 Aug 2023 21:31:34 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
Message-ID: <o0LG8T-_-Ce2EWKO9kwLoG7InRKy9Go9-eTSawjMPUA=.a8fcbd5b-40ff-4ab3-ac27-161310b6e7a7@github.com>

On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make bytecode.hpp index() functions return u2 not long.

src/hotspot/share/runtime/deoptimization.cpp line 255:

> 253:     result += frame_sizes()[index];
> 254:   }
> 255:   return checked_cast<int>(result);

Isn't _caller_adjustment already an int?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287706980

From dlong at openjdk.org  Tue Aug  8 21:41:33 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 8 Aug 2023 21:41:33 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
Message-ID: <8svWRRP4NxnJb2S-I0zP_q5TVuptLBsAp095rNoMo1Y=.8cfde906-5c79-46b5-b9be-adf5c12b3cc9@github.com>

On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make bytecode.hpp index() functions return u2 not long.

src/hotspot/share/runtime/java.hpp line 108:

> 106: 
> 107:   // Factory methods for convenience
> 108:   static JDK_Version jdk(int m) {

Finally, support for JDK 256 and beyond!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287713839

From dlong at openjdk.org  Tue Aug  8 22:03:33 2023
From: dlong at openjdk.org (Dean Long)
Date: Tue, 8 Aug 2023 22:03:33 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
Message-ID: <QobJXxGrjj4NwOSdgUOj0T-XifmsOCnXvt0sm3f6iJk=.8d1820dd-eb77-4ab4-b831-af16b511b6ae@github.com>

On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make bytecode.hpp index() functions return u2 not long.

src/hotspot/share/runtime/objectMonitor.hpp line 238:

> 236:   //
> 237:   #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \
> 238:     ((in_bytes(ObjectMonitor::f ## _offset())) - (unsigned)markWord::monitor_value)

This makes it int vs uint (-Wsign-conversion warning), and assumes the range of monitor_value.
One option is to narrow the type of monitor_value.  Option 2, cast the lhs to uintptr_t.  Option 3, use offset_of instead of signed ByteSize.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287727808

From pchilanomate at openjdk.org  Tue Aug  8 22:17:39 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 8 Aug 2023 22:17:39 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
Message-ID: <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com>

On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make bytecode.hpp index() functions return u2 not long.

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

> 141:     milliseconds_since_19700101 / milliseconds_per_microsecond;
> 142:   const int milliseconds_after_second =
> 143:     checked_cast<int>(milliseconds_since_19700101 % milliseconds_per_microsecond);

Not related to this change but seems milliseconds_per_microsecond should be named milliseconds_per_second.

src/hotspot/share/runtime/safepoint.cpp line 98:

> 96:                                              int initial_number_of_threads,
> 97:                                              int threads_waiting_to_block,
> 98:                                              int iterations) {

Maybe leave iterations as unsigned and change the caller instead?

src/hotspot/share/runtime/sharedRuntime.cpp line 2348:

> 2346:     double sum = 0;
> 2347:     double weighted_sum = 0;
> 2348:     for (int i = 0; i <= n; i++) { sum += (double)histo[i]; weighted_sum += (double)(i*histo[i]); }

So hist is a uint64_t*, why can't we make sum and weighted_sum just uint64_t?

src/hotspot/share/runtime/threadHeapSampler.cpp line 359:

> 357:          "double and uint64_t do not have the same size");
> 358:   x = *reinterpret_cast<const uint64_t*>(&d);
> 359:   const uint32_t x_high = (uint32_t)(x >> 32);

Can't we do a checked_cast here? The cast should be reversible with that shift value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287725795
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287728163
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287734252
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287733638

From coleenp at openjdk.org  Wed Aug  9 00:58:32 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 00:58:32 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
Message-ID: <AXId03LiaWx8-cMvvkK8CeT30k1t0v-vaS7WPG9muMs=.ab48b99b-b1b5-49ae-a501-de89b6553f12@github.com>

On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make bytecode.hpp index() functions return u2 not long.

Thank you Dean and Patricio for your comments on this change.

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

PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1568509515

From coleenp at openjdk.org  Wed Aug  9 00:58:37 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 00:58:37 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <yabO0a_IUVrINjWH29ARdKH1URnnrJZk-hJb1GU4dI4=.08134cee-265a-4070-bb32-670b06394cf0@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <yabO0a_IUVrINjWH29ARdKH1URnnrJZk-hJb1GU4dI4=.08134cee-265a-4070-bb32-670b06394cf0@github.com>
Message-ID: <yLaS4N5mf9VtxiVt_1nGvp_HdOi6_tK_-KGj5Nm6ltI=.03e3f793-e649-44c6-8aa6-34609e8d9d15@github.com>

On Tue, 8 Aug 2023 21:09:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make bytecode.hpp index() functions return u2 not long.
>
> src/hotspot/share/runtime/arguments.cpp line 1667:
> 
>> 1665: 
>> 1666:     if (InitialHeapSize == 0) {
>> 1667:       julong reasonable_initial = (julong)((phys_mem * (julong)InitialRAMPercentage) / 100);
> 
> This and the two changes above loses the fractional part.
> Suggestion:
> 
>       julong reasonable_initial = (julong)((double)phys_mem * InitialRAMPercentage / 100.0);

Thanks, yes. That's wrong.

> src/hotspot/share/runtime/arguments.cpp line 2738:
> 
>> 2736:       }
>> 2737: 
>> 2738:       if (FLAG_SET_CMDLINE(MaxTenuringThreshold, (uint)max_tenuring_thresh) != JVMFlag::SUCCESS) {
> 
> MaxTenuringThreshold was recently changed to uint, so it would make sense change uintx above to uint.

I couldn't change that one because there isn't a parse_uint() version of this:
      if (!parse_uintx(tail, &max_tenuring_thresh, 0)) {
Which calls parse_integer into a 64 bit value.

> src/hotspot/share/runtime/deoptimization.cpp line 255:
> 
>> 253:     result += frame_sizes()[index];
>> 254:   }
>> 255:   return checked_cast<int>(result);
> 
> Isn't _caller_adjustment already an int?

frame_sizes() returns intptr_t so I had to promote result, then demote it.  frame_sizes() is a more difficult change.

runtime/deoptimization.hpp:    intptr_t* _frame_sizes;               // Array of frame sizes, in bytes, for unrolling the stack

> src/hotspot/share/runtime/java.hpp line 108:
> 
>> 106: 
>> 107:   // Factory methods for convenience
>> 108:   static JDK_Version jdk(int m) {
> 
> Finally, support for JDK 256 and beyond!

Hooray!

> src/hotspot/share/runtime/objectMonitor.hpp line 238:
> 
>> 236:   //
>> 237:   #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \
>> 238:     ((in_bytes(ObjectMonitor::f ## _offset())) - (unsigned)markWord::monitor_value)
> 
> This makes it int vs uint (-Wsign-conversion warning), and assumes the range of monitor_value.
> One option is to narrow the type of monitor_value.  Option 2, cast the lhs to uintptr_t.  Option 3, use offset_of instead of signed ByteSize.

I looked at option 1, but monitor_value is used for byte operations, and it seemed unsafe to make it smaller than uintptr_t, eg:

oops/markWord.hpp:    return markWord(tmp | monitor_value);

The -Wconversion warning is complaining about OM_OFFSET_NO_MONITOR_VALUE_TAG is an long unsigned int because the expression is promoted to the size of markWord::monitor_value without the cast.

Option 3 turns the address into a 64 bit int, but the Address constructor expects a 32 bit displacement.

   88 |   __ movptr(Address(mon, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), r15_thread);

Should this convert to int instead of unsigned instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287791980
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287793204
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287794097
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287794217
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287800508

From coleenp at openjdk.org  Wed Aug  9 00:58:41 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 00:58:41 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com>
Message-ID: <xNFSpzJxdCT-PsNkvYiaQn2wiST1ZOLRIW8zzx6yXas=.6500cb19-b7fa-486d-bc29-592147a524ba@github.com>

On Tue, 8 Aug 2023 21:57:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make bytecode.hpp index() functions return u2 not long.
>
> src/hotspot/share/runtime/os.cpp line 143:
> 
>> 141:     milliseconds_since_19700101 / milliseconds_per_microsecond;
>> 142:   const int milliseconds_after_second =
>> 143:     checked_cast<int>(milliseconds_since_19700101 % milliseconds_per_microsecond);
> 
> Not related to this change but seems milliseconds_per_microsecond should be named milliseconds_per_second.

That's easily fixed, and I've already changed those lines.

> src/hotspot/share/runtime/safepoint.cpp line 98:
> 
>> 96:                                              int initial_number_of_threads,
>> 97:                                              int threads_waiting_to_block,
>> 98:                                              int iterations) {
> 
> Maybe leave iterations as unsigned and change the caller instead?

If I change the caller: synchronize_threads, it returns the parameter iterations, so I'd have to change its callers.  Everything uses iterations here as an int, other than this parameter.

> src/hotspot/share/runtime/sharedRuntime.cpp line 2348:
> 
>> 2346:     double sum = 0;
>> 2347:     double weighted_sum = 0;
>> 2348:     for (int i = 0; i <= n; i++) { sum += (double)histo[i]; weighted_sum += (double)(i*histo[i]); }
> 
> So hist is a uint64_t*, why can't we make sum and weighted_sum just uint64_t?

I think there were less casts this way, since sum and weighted sum had to be turned into double more than histo[i], but it does make more sense to use int for summing the numbers, and cast to double for printing.

> src/hotspot/share/runtime/threadHeapSampler.cpp line 359:
> 
>> 357:          "double and uint64_t do not have the same size");
>> 358:   x = *reinterpret_cast<const uint64_t*>(&d);
>> 359:   const uint32_t x_high = (uint32_t)(x >> 32);
> 
> Can't we do a checked_cast here? The cast should be reversible with that shift value.

I think so.  I was afraid of sign extension so I just wanted to chop it off, also didn't seem necessary to check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287801694
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287802613
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287805610
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287819364

From dlong at openjdk.org  Wed Aug  9 01:35:32 2023
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Aug 2023 01:35:32 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <yLaS4N5mf9VtxiVt_1nGvp_HdOi6_tK_-KGj5Nm6ltI=.03e3f793-e649-44c6-8aa6-34609e8d9d15@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <yabO0a_IUVrINjWH29ARdKH1URnnrJZk-hJb1GU4dI4=.08134cee-265a-4070-bb32-670b06394cf0@github.com>
 <yLaS4N5mf9VtxiVt_1nGvp_HdOi6_tK_-KGj5Nm6ltI=.03e3f793-e649-44c6-8aa6-34609e8d9d15@github.com>
Message-ID: <q2RsNlzByCw2ZP9CoalBOsnWydFO3UGDivnSsPV3PSo=.4a643403-814e-4825-b61b-5350e6140399@github.com>

On Tue, 8 Aug 2023 23:55:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 2738:
>> 
>>> 2736:       }
>>> 2737: 
>>> 2738:       if (FLAG_SET_CMDLINE(MaxTenuringThreshold, (uint)max_tenuring_thresh) != JVMFlag::SUCCESS) {
>> 
>> MaxTenuringThreshold was recently changed to uint, so it would make sense change uintx above to uint.
>
> I couldn't change that one because there isn't a parse_uint() version of this:
>       if (!parse_uintx(tail, &max_tenuring_thresh, 0)) {
> Which calls parse_integer into a 64 bit value.

Isn't parse_integer() used to parse int flags?  It's a template.

>> src/hotspot/share/runtime/deoptimization.cpp line 255:
>> 
>>> 253:     result += frame_sizes()[index];
>>> 254:   }
>>> 255:   return checked_cast<int>(result);
>> 
>> Isn't _caller_adjustment already an int?
>
> frame_sizes() returns intptr_t so I had to promote result, then demote it.  frame_sizes() is a more difficult change.
> 
> runtime/deoptimization.hpp:    intptr_t* _frame_sizes;               // Array of frame sizes, in bytes, for unrolling the stack

OK, I missed the +=.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287836477
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287836596

From dlong at openjdk.org  Wed Aug  9 01:44:35 2023
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Aug 2023 01:44:35 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <yLaS4N5mf9VtxiVt_1nGvp_HdOi6_tK_-KGj5Nm6ltI=.03e3f793-e649-44c6-8aa6-34609e8d9d15@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <yabO0a_IUVrINjWH29ARdKH1URnnrJZk-hJb1GU4dI4=.08134cee-265a-4070-bb32-670b06394cf0@github.com>
 <yLaS4N5mf9VtxiVt_1nGvp_HdOi6_tK_-KGj5Nm6ltI=.03e3f793-e649-44c6-8aa6-34609e8d9d15@github.com>
Message-ID: <MWFbKyWmeiPbxBjq18WtHNfnRgFLElcAIC9KqylCsRA=.28f9e163-ade8-4397-9e51-7268bcf8acfc@github.com>

On Wed, 9 Aug 2023 00:12:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 238:
>> 
>>> 236:   //
>>> 237:   #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \
>>> 238:     ((in_bytes(ObjectMonitor::f ## _offset())) - (unsigned)markWord::monitor_value)
>> 
>> This makes it int vs uint (-Wsign-conversion warning), and assumes the range of monitor_value.
>> One option is to narrow the type of monitor_value.  Option 2, cast the lhs to uintptr_t.  Option 3, use offset_of instead of signed ByteSize.
>
> I looked at option 1, but monitor_value is used for byte operations, and it seemed unsafe to make it smaller than uintptr_t, eg:
> 
> oops/markWord.hpp:    return markWord(tmp | monitor_value);
> 
> The -Wconversion warning is complaining about OM_OFFSET_NO_MONITOR_VALUE_TAG is an long unsigned int because the expression is promoted to the size of markWord::monitor_value without the cast.
> 
> Option 3 turns the address into a 64 bit int, but the Address constructor expects a 32 bit displacement.
> 
>    88 |   __ movptr(Address(mon, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), r15_thread);
> 
> Should this convert to int instead of unsigned instead?

Yes int would be more correct.  The value could be negative if the order of the fields in ObjectMonitor (or the value of monitor_value) were changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287840806

From dlong at openjdk.org  Wed Aug  9 01:52:43 2023
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Aug 2023 01:52:43 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <xNFSpzJxdCT-PsNkvYiaQn2wiST1ZOLRIW8zzx6yXas=.6500cb19-b7fa-486d-bc29-592147a524ba@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com>
 <xNFSpzJxdCT-PsNkvYiaQn2wiST1ZOLRIW8zzx6yXas=.6500cb19-b7fa-486d-bc29-592147a524ba@github.com>
Message-ID: <9bzTnUcEvSuqdaVEr0XI2yR2SEf5OUZ8ro7WhtxDeHw=.cf065626-a648-4028-b997-280871690af6@github.com>

On Wed, 9 Aug 2023 00:24:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntime.cpp line 2348:
>> 
>>> 2346:     double sum = 0;
>>> 2347:     double weighted_sum = 0;
>>> 2348:     for (int i = 0; i <= n; i++) { sum += (double)histo[i]; weighted_sum += (double)(i*histo[i]); }
>> 
>> So hist is a uint64_t*, why can't we make sum and weighted_sum just uint64_t?
>
> I think there were less casts this way, since sum and weighted sum had to be turned into double more than histo[i], but it does make more sense to use int for summing the numbers, and cast to double for printing.

I don't know how big these values are, but if they were large then uint64_t sum could overflow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287844731

From dholmes at openjdk.org  Wed Aug  9 07:40:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Aug 2023 07:40:28 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v3]
In-Reply-To: <K798OIt0CzV1LKFjovZU-M6c160RfsurzFO4gMQRtZ8=.ebbe869c-bf1e-4dcd-a6e0-05dee3c70bba@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <K798OIt0CzV1LKFjovZU-M6c160RfsurzFO4gMQRtZ8=.ebbe869c-bf1e-4dcd-a6e0-05dee3c70bba@github.com>
Message-ID: <FPXwg_2OpDUQEeVC0pHdEriSE82nb6ixr3wnUepmwPU=.6d54173f-1cd7-49f8-8eef-4089e8fb0735@github.com>

On Tue, 8 Aug 2023 12:21:53 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   backslash aligned

I only checked the last two flags but in both cases found related changes. Please make sure all the uses of these flags has been checked. Thanks.

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

> 1309:           "Hit breakpoint when mallocing/freeing this pointer")             \
> 1310:                                                                             \
> 1311:   develop(int, StackPrintLimit, 100,                                        \

You can remove this cast now:

./share/utilities/vmError.cpp:    const int limit = max_frames == -1 ? StackPrintLimit : MIN2(max_frames, (int)StackPrintLimit);

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

> 1746:           "Data sampling interval (in milliseconds)")                       \
> 1747:           range(PeriodicTask::min_interval, max_jint)                       \
> 1748:           constraint(PerfDataSamplingIntervalFunc, AfterErgo)               \

You need to change the type of the `PerfDataSamplingIntervalFunc` as well.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1568895310
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288053102
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288049092

From dholmes at openjdk.org  Wed Aug  9 07:41:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Aug 2023 07:41:29 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v3]
In-Reply-To: <RjU1qMXK2exKM22cu9uTfO42ktOomR8C8eO_lHwWy8M=.74562de4-e5ac-454a-b090-913d54d28f88@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
 <jn0WipGq3PQjZqzIpzytEkI3cEon2n2bxk8xTJX1VgE=.84daa763-cd40-4183-9839-f7ad91fbc633@github.com>
 <thTuLZnkW8d97JzhNjsA1gbjC52sF4FM_1TiVgvnC2U=.0937bb38-51c6-4ff7-951f-6ca5a7134793@github.com>
 <e9haO0Qu8ywQI39G0A87mXN60oyiKhvBoLW6lDy_W-w=.6b5f8228-95fd-432e-b5de-bf6130acbbaf@github.com>
 <qlMDwXhreLvHQcFBjGU4MCW4PnDzgGG35NLOYWVlQhQ=.6c08a83f-4218-4a10-a4df-47d7a286bbaf@github.com>
 <RjU1qMXK2exKM22cu9uTfO42ktOomR8C8eO_lHwWy8M=.74562de4-e5ac-454a-b090-913d54d28f88@github.com>
Message-ID: <2_ComSBzrXfSK7XOT3Fzzc616tXIHtR_7yaqM3c0sME=.19f45af2-161b-42bd-9f47-dbabbc66c863@github.com>

On Mon, 7 Aug 2023 14:52:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms.
>
> This is complicated.  BytecodeCounter::_counter_value is an int, and StopInterpreterAt compares to that in shared code, which is fine because it'll promote the former to intx.  The cpu-specific code fetches the former as int and the latter as intx, except in one place so fixing either is going to be work.  The one place that complains on x86 is 
> 
> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp:1865:12: warning: conversion from 'intx' {aka 'long int'} to 'int32_t' {aka 'int'} may change value [-Wconversion]
>  1865 |            StopInterpreterAt,
>       |            ^~~~~~~~~~~~~~~~~
> 
> 
>   __ cmp32(ExternalAddress((address) &BytecodeCounter::_counter_value),
>            StopInterpreterAt,
>            rscratch1);
> 
> We could just static_cast StopInterpreterAt to int here.

> Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms.

I thought this was the count within a method, in which case the bytecode limit is the same for 32-bit and 64-bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288037015

From dlong at openjdk.org  Wed Aug  9 09:08:59 2023
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Aug 2023 09:08:59 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v2]
In-Reply-To: <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
Message-ID: <Rtnwno_fbTT9f_pkahS4c0QGMSW7tSbCbNpZ5L0t9JE=.4ebbfdc1-8acd-42f9-9824-7f5898233af8@github.com>

On Thu, 3 Aug 2023 07:12:08 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
>> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update is_intrinsic_supported for _dcopySign,_fcopySign.

I don't having the same logic in two places, because then those two places need to be kept in sync.  Either the stubs should be generated based on is_intrinsic_supported(), or is_intrinsic_supported() should check if the stub was generated.

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

PR Comment: https://git.openjdk.org/jdk/pull/15133#issuecomment-1670921720

From dnsimon at openjdk.org  Wed Aug  9 09:56:29 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 9 Aug 2023 09:56:29 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
Message-ID: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>

In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:

java.lang.OutOfMemoryError: Metaspace
        at jdk.internal.vm.TranslatedException.encodeThrowable([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/TranslatedException.java:176)
        at jdk.internal.vm.TranslatedException.<clinit>([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/TranslatedException.java:61)
        at jdk.internal.vm.VMSupport.encodeThrowable([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/VMSupport.java:171)

This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.

The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

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

Commit messages:
 - handle exception in TranslatedException.<clinit> (JDK-8313899)

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

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

From never at openjdk.org  Wed Aug  9 09:56:29 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 9 Aug 2023 09:56:29 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <yOZ1jB0NNvOw3IaiayZqMYBqDd3prXTbA6sjPmQy1Ck=.50e4ceb8-9578-43bd-830a-dd3aa09cc88d@github.com>

On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

Looks good.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15198#pullrequestreview-1568664065

From azafari at openjdk.org  Wed Aug  9 11:36:34 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 9 Aug 2023 11:36:34 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v4]
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <eIxgKxbuA_pRgTNbO4z5pslzSwi-QsmAP-OY4vUg5DQ=.81920357-8ef1-40ad-9796-8563f6319178@github.com>

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  checked all usages of changed options.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15164/files
  - new: https://git.openjdk.org/jdk/pull/15164/files/d88a1238..d7919b1b

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

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

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

From coleenp at openjdk.org  Wed Aug  9 12:00:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 12:00:28 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v4]
In-Reply-To: <2_ComSBzrXfSK7XOT3Fzzc616tXIHtR_7yaqM3c0sME=.19f45af2-161b-42bd-9f47-dbabbc66c863@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <YTLjqzhKm9FolwKjokpyvd8_xcMJzW-diN8RqNEGVxo=.a4764617-17b2-46c7-be92-2be2b8aeda2f@github.com>
 <jn0WipGq3PQjZqzIpzytEkI3cEon2n2bxk8xTJX1VgE=.84daa763-cd40-4183-9839-f7ad91fbc633@github.com>
 <thTuLZnkW8d97JzhNjsA1gbjC52sF4FM_1TiVgvnC2U=.0937bb38-51c6-4ff7-951f-6ca5a7134793@github.com>
 <e9haO0Qu8ywQI39G0A87mXN60oyiKhvBoLW6lDy_W-w=.6b5f8228-95fd-432e-b5de-bf6130acbbaf@github.com>
 <qlMDwXhreLvHQcFBjGU4MCW4PnDzgGG35NLOYWVlQhQ=.6c08a83f-4218-4a10-a4df-47d7a286bbaf@github.com>
 <RjU1qMXK2exKM22cu9uTfO42ktOomR8C8eO_lHwWy8M=.74562de4-e5ac-454a-b090-913d54d28f88@github.com>
 <2_ComSBzrXfSK7XOT3Fzzc616tXIHtR_7yaqM3c0sME=.19f45af2-161b-42bd-9f47-dbabbc66c863@github.com>
Message-ID: <jezKCdYP3wO_9q8fXDUXzc2DPzdoJFFBFpoZAvo-TOc=.2209c81d-1ce0-4a57-9ad6-f1b3235747da@github.com>

On Wed, 9 Aug 2023 07:01:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is complicated.  BytecodeCounter::_counter_value is an int, and StopInterpreterAt compares to that in shared code, which is fine because it'll promote the former to intx.  The cpu-specific code fetches the former as int and the latter as intx, except in one place so fixing either is going to be work.  The one place that complains on x86 is 
>> 
>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp:1865:12: warning: conversion from 'intx' {aka 'long int'} to 'int32_t' {aka 'int'} may change value [-Wconversion]
>>  1865 |            StopInterpreterAt,
>>       |            ^~~~~~~~~~~~~~~~~
>> 
>> 
>>   __ cmp32(ExternalAddress((address) &BytecodeCounter::_counter_value),
>>            StopInterpreterAt,
>>            rscratch1);
>> 
>> We could just static_cast StopInterpreterAt to int here.
>
>> Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms.
> 
> I thought this was the count within a method, in which case the bytecode limit is the same for 32-bit and 64-bit.

It is not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288371386

From coleenp at openjdk.org  Wed Aug  9 12:20:58 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 12:20:58 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v3]
In-Reply-To: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
Message-ID: <89uyh0jvDyytOfu-OI8Z2vO0v96FI0oK0uFTuLJ_HY8=.b44d6b53-67dd-4ad3-ba2d-86ae508e024e@github.com>

> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
> 
> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>       |                                     ~~~~^~~
> 
> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Dean's and Patricio's suggested changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15177/files
  - new: https://git.openjdk.org/jdk/pull/15177/files/a77884e4..1af1cfe5

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

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

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

From azafari at openjdk.org  Wed Aug  9 12:41:28 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 9 Aug 2023 12:41:28 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v5]
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <3xjlUAvmX9Vp4T4a0Q4OIrJuLs6eWUiQ6udipPiM_v8=.ba115f8a-ad56-4643-a1f1-cc0a223668f0@github.com>

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  Matched with master.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15164/files
  - new: https://git.openjdk.org/jdk/pull/15164/files/d7919b1b..361a3d9a

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

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

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

From coleenp at openjdk.org  Wed Aug  9 13:23:40 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 13:23:40 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v4]
In-Reply-To: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
Message-ID: <JOF2NfkTy5nC16Koimk3sQcKPfaR114-bveyIsxCAEY=.88316c1d-4ac1-472d-b9b5-6dbb6960f3dd@github.com>

> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
> 
> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>       |                                     ~~~~^~~
> 
> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.

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

 - Merge branch 'master' into runtime-conversion
 - Change Arguments::parse_uintx to parse_uint and callers.
 - Dean's and Patricio's suggested changes.
 - Make bytecode.hpp index() functions return u2 not long.
 - Fix jvmci for held_monitor_count type.
 - Fix format strings for monitor_counts and fix arguments.cpp differently.
 - Fix gtests
 - Fix asserted files in runtime with one warning.
 - Fix signature.cpp
 - Fix continuationFreezeThaw.cpp
 - ... and 7 more: https://git.openjdk.org/jdk/compare/e4063a36...f4961655

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15177/files
  - new: https://git.openjdk.org/jdk/pull/15177/files/1af1cfe5..f4961655

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

  Stats: 7972 lines in 425 files changed: 2632 ins; 2838 del; 2502 mod
  Patch: https://git.openjdk.org/jdk/pull/15177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177

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

From coleenp at openjdk.org  Wed Aug  9 13:24:00 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 13:24:00 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <q2RsNlzByCw2ZP9CoalBOsnWydFO3UGDivnSsPV3PSo=.4a643403-814e-4825-b61b-5350e6140399@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <yabO0a_IUVrINjWH29ARdKH1URnnrJZk-hJb1GU4dI4=.08134cee-265a-4070-bb32-670b06394cf0@github.com>
 <yLaS4N5mf9VtxiVt_1nGvp_HdOi6_tK_-KGj5Nm6ltI=.03e3f793-e649-44c6-8aa6-34609e8d9d15@github.com>
 <q2RsNlzByCw2ZP9CoalBOsnWydFO3UGDivnSsPV3PSo=.4a643403-814e-4825-b61b-5350e6140399@github.com>
Message-ID: <kzg0vUVbHOFocX1WYQVBJgyGwZVtX9lLNNIxwqHcbuI=.88bd6488-8c12-427b-9809-624f5d6f56b6@github.com>

On Wed, 9 Aug 2023 01:32:37 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I couldn't change that one because there isn't a parse_uint() version of this:
>>       if (!parse_uintx(tail, &max_tenuring_thresh, 0)) {
>> Which calls parse_integer into a 64 bit value.
>
> Isn't parse_integer() used to parse int flags?  It's a template.

Ok, I fixed parse_uintx in Arguments to parse_uint then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288440009

From coleenp at openjdk.org  Wed Aug  9 13:24:02 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 13:24:02 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <9bzTnUcEvSuqdaVEr0XI2yR2SEf5OUZ8ro7WhtxDeHw=.cf065626-a648-4028-b997-280871690af6@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com>
 <xNFSpzJxdCT-PsNkvYiaQn2wiST1ZOLRIW8zzx6yXas=.6500cb19-b7fa-486d-bc29-592147a524ba@github.com>
 <9bzTnUcEvSuqdaVEr0XI2yR2SEf5OUZ8ro7WhtxDeHw=.cf065626-a648-4028-b997-280871690af6@github.com>
Message-ID: <8WXIOuCKXYoIfkmw14aQ36Wf2ZBm2lqYpxwcBnyxCQ8=.8f583a22-9ee4-4489-bef6-f4cca99564b3@github.com>

On Wed, 9 Aug 2023 01:49:43 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I think there were less casts this way, since sum and weighted sum had to be turned into double more than histo[i], but it does make more sense to use int for summing the numbers, and cast to double for printing.
>
> I don't know how big these values are, but if they were large then uint64_t sum could overflow.

uint64_t count = (uint64_t)method->compiled_invocation_count();

They seem to be a sum of compiled_invocation_count() so maybe double is best.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288453974

From coleenp at openjdk.org  Wed Aug  9 14:14:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 14:14:28 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v5]
In-Reply-To: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
Message-ID: <gzqAIOOBgegD-Tl-dpV8qYtpHBVA4pHdhp4t5ji7ph4=.3cdc2b79-72e2-4e63-8465-d3028a92170e@github.com>

> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
> 
> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>       |                                     ~~~~^~~
> 
> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Revert histogram sum and weighted_sum changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15177/files
  - new: https://git.openjdk.org/jdk/pull/15177/files/f4961655..43665637

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

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

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

From coleenp at openjdk.org  Wed Aug  9 14:18:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 14:18:29 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <8WXIOuCKXYoIfkmw14aQ36Wf2ZBm2lqYpxwcBnyxCQ8=.8f583a22-9ee4-4489-bef6-f4cca99564b3@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com>
 <xNFSpzJxdCT-PsNkvYiaQn2wiST1ZOLRIW8zzx6yXas=.6500cb19-b7fa-486d-bc29-592147a524ba@github.com>
 <9bzTnUcEvSuqdaVEr0XI2yR2SEf5OUZ8ro7WhtxDeHw=.cf065626-a648-4028-b997-280871690af6@github.com>
 <8WXIOuCKXYoIfkmw14aQ36Wf2ZBm2lqYpxwcBnyxCQ8=.8f583a22-9ee4-4489-bef6-f4cca99564b3@github.com>
Message-ID: <BIxZpLiik346YPZgJbPgMPWNQTefL7XJEO_dUhJkkj8=.2c4766a8-c317-48f2-9815-5e796b6363bd@github.com>

On Wed, 9 Aug 2023 13:06:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I don't know how big these values are, but if they were large then uint64_t sum could overflow.
>
> uint64_t count = (uint64_t)method->compiled_invocation_count();
> 
> They seem to be a sum of compiled_invocation_count() so maybe double is best.

I reverted this to change sum and weighed_sum back to double, and add the cast back to histo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288516748

From coleenp at openjdk.org  Wed Aug  9 14:15:04 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 14:15:04 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com>
Message-ID: <pwj2_JKquMhJzbcqWQyDZ0qmFtd6UC8eejTehkXN6BI=.6f826144-1879-4d8c-b58c-2b9e693a95ee@github.com>

On Tue, 8 Aug 2023 20:10:48 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make bytecode.hpp index() functions return u2 not long.
>
> src/hotspot/share/runtime/arguments.cpp line 1215:
> 
>> 1213:       }
>> 1214:     }
>> 1215:     c = getc(stream);
> 
> How about int c0 for the getc value, then the first line in the loop does
> char c = checked_cast<char>(c0);
> No other changes should be needed.

There was a reason that c had to be an int.  Now I'll have to rebuild and figure it out again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288514952

From azafari at openjdk.org  Wed Aug  9 14:54:04 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 9 Aug 2023 14:54:04 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v6]
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <D_EpjNlhKVe3j24sxYotmOFOehi1YISaJHs8CRVZc3I=.d2f9e273-d79b-48ea-ad70-f18025b7d29c@github.com>

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into wconv_jvm_options
 - Matched with master.
 - checked all usages of changed options.
 - backslash aligned
 - Review comments applied.
 - Fixed intx->int for Wconversion warnings.

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

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

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

From azafari at openjdk.org  Wed Aug  9 14:54:30 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 9 Aug 2023 14:54:30 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v3]
In-Reply-To: <FPXwg_2OpDUQEeVC0pHdEriSE82nb6ixr3wnUepmwPU=.6d54173f-1cd7-49f8-8eef-4089e8fb0735@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <K798OIt0CzV1LKFjovZU-M6c160RfsurzFO4gMQRtZ8=.ebbe869c-bf1e-4dcd-a6e0-05dee3c70bba@github.com>
 <FPXwg_2OpDUQEeVC0pHdEriSE82nb6ixr3wnUepmwPU=.6d54173f-1cd7-49f8-8eef-4089e8fb0735@github.com>
Message-ID: <vfdoAYe9AGVwR0DnwCCgP2XZNGO09Fclk3irqvrRv6s=.e262ef8c-3437-4b15-8da5-c740f63c2416@github.com>

On Wed, 9 Aug 2023 07:17:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   backslash aligned
>
> src/hotspot/share/runtime/globals.hpp line 1311:
> 
>> 1309:           "Hit breakpoint when mallocing/freeing this pointer")             \
>> 1310:                                                                             \
>> 1311:   develop(int, StackPrintLimit, 100,                                        \
> 
> You can remove this cast now:
> 
> ./share/utilities/vmError.cpp:    const int limit = max_frames == -1 ? StackPrintLimit : MIN2(max_frames, (int)StackPrintLimit);

Fixed.

> src/hotspot/share/runtime/globals.hpp line 1748:
> 
>> 1746:           "Data sampling interval (in milliseconds)")                       \
>> 1747:           range(PeriodicTask::min_interval, max_jint)                       \
>> 1748:           constraint(PerfDataSamplingIntervalFunc, AfterErgo)               \
> 
> You need to change the type of the `PerfDataSamplingIntervalFunc` as well.

I changed this and checked for the other options I changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288598106
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288601635

From azafari at openjdk.org  Wed Aug  9 15:05:28 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 9 Aug 2023 15:05:28 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v5]
In-Reply-To: <3xjlUAvmX9Vp4T4a0Q4OIrJuLs6eWUiQ6udipPiM_v8=.ba115f8a-ad56-4643-a1f1-cc0a223668f0@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <3xjlUAvmX9Vp4T4a0Q4OIrJuLs6eWUiQ6udipPiM_v8=.ba115f8a-ad56-4643-a1f1-cc0a223668f0@github.com>
Message-ID: <YQHu5gzOvImjlylNRtzJlqTqGgn8pW-Pxbqdg4q-0_4=.74eb55c3-e369-429b-b9fb-8b275a2fe3e0@github.com>

On Wed, 9 Aug 2023 12:41:28 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Matched with master.

I also changed the type of LogEventsBufferEntries in `runtime/globals.hpp` which fixes the Wconversion warnings in `utilities/events.hpp`.

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

PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1671531536

From coleenp at openjdk.org  Wed Aug  9 15:43:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 15:43:28 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6]
In-Reply-To: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
Message-ID: <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>

> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
> 
> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>       |                                     ~~~~^~~
> 
> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - put checked_cast around getc().
 - put checked_cast around getc().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15177/files
  - new: https://git.openjdk.org/jdk/pull/15177/files/43665637..17eaec50

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

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

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

From coleenp at openjdk.org  Wed Aug  9 16:52:59 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 16:52:59 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <pwj2_JKquMhJzbcqWQyDZ0qmFtd6UC8eejTehkXN6BI=.6f826144-1879-4d8c-b58c-2b9e693a95ee@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com>
 <pwj2_JKquMhJzbcqWQyDZ0qmFtd6UC8eejTehkXN6BI=.6f826144-1879-4d8c-b58c-2b9e693a95ee@github.com>
Message-ID: <JJ1Fv8JlW6aZLT0vKA-EW5oBbeof9L-0PG38Nq6EplI=.6a18c20e-6a07-4cce-b138-521650ab9bf5@github.com>

On Wed, 9 Aug 2023 13:49:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 1215:
>> 
>>> 1213:       }
>>> 1214:     }
>>> 1215:     c = getc(stream);
>> 
>> How about int c0 for the getc value, then the first line in the loop does
>> char c = checked_cast<char>(c0);
>> No other changes should be needed.
>
> There was a reason that c had to be an int.  Now I'll have to rebuild and figure it out again.

No, it works and is a bit better, so I made this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288883114

From pchilanomate at openjdk.org  Wed Aug  9 19:52:58 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 9 Aug 2023 19:52:58 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6]
In-Reply-To: <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
Message-ID: <C7nqfH7plhoxrPNvs-TuzFGy_z19OamKHkXfnjsrVb4=.dad2ba9d-67cd-45e8-a082-574491d12551@github.com>

On Wed, 9 Aug 2023 15:43:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - put checked_cast around getc().
>  - put checked_cast around getc().

Thanks for the fixes. Looks good to me.

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

> 1182: 
> 1183:   char c = checked_cast<char>(getc(stream));
> 1184:   while(c != EOF && pos < (int)(sizeof(token)-1)) {

I see error in some builds due to the EOF comparison though now that c is a char.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1570400279
PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289118732

From dlong at openjdk.org  Wed Aug  9 20:05:58 2023
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Aug 2023 20:05:58 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6]
In-Reply-To: <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
Message-ID: <OH_CeOjc5EqPaQIwGpnGe8ct3MKCeHOB49FJMixDrkI=.fcefed3a-6a8e-49c6-b269-ab2a4c7c979e@github.com>

On Wed, 9 Aug 2023 15:43:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - put checked_cast around getc().
>  - put checked_cast around getc().

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

> 1181:   bool result         = true;
> 1182: 
> 1183:   char c = checked_cast<char>(getc(stream));

I think this only works if "char" is signed, because EOF is -1.  What I meant was:

int c0 = getc(stream);
while (c0 != EOF ...) {
  char c = checked_cast<char>(c0);
  ...
  c0 = getc(stream);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289134766

From pchilanomate at openjdk.org  Wed Aug  9 20:07:28 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 9 Aug 2023 20:07:28 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <JJ1Fv8JlW6aZLT0vKA-EW5oBbeof9L-0PG38Nq6EplI=.6a18c20e-6a07-4cce-b138-521650ab9bf5@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com>
 <pwj2_JKquMhJzbcqWQyDZ0qmFtd6UC8eejTehkXN6BI=.6f826144-1879-4d8c-b58c-2b9e693a95ee@github.com>
 <JJ1Fv8JlW6aZLT0vKA-EW5oBbeof9L-0PG38Nq6EplI=.6a18c20e-6a07-4cce-b138-521650ab9bf5@github.com>
Message-ID: <9_wskfUjYqTIOG27mpDmO_ltC1RDl_GclltIsfZOQPw=.1447c996-764a-4d7a-96c8-2bf6e72bd85e@github.com>

On Wed, 9 Aug 2023 16:40:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There was a reason that c had to be an int.  Now I'll have to rebuild and figure it out again.
>
> No, it works and is a bit better, so I made this change.

I see error in some builds due to the EOF comparison though now that c is a char. I think Dean was suggesting doing the cast inside the loop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289124669

From coleenp at openjdk.org  Wed Aug  9 20:23:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 20:23:28 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6]
In-Reply-To: <OH_CeOjc5EqPaQIwGpnGe8ct3MKCeHOB49FJMixDrkI=.fcefed3a-6a8e-49c6-b269-ab2a4c7c979e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
 <OH_CeOjc5EqPaQIwGpnGe8ct3MKCeHOB49FJMixDrkI=.fcefed3a-6a8e-49c6-b269-ab2a4c7c979e@github.com>
Message-ID: <jVJJK5R8v5gUnIu3wDNYNDeYiSxBWSuAkOjxt1JIbHQ=.8b7ba937-2062-48cc-beee-fabf74c66746@github.com>

On Wed, 9 Aug 2023 20:02:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - put checked_cast around getc().
>>  - put checked_cast around getc().
>
> src/hotspot/share/runtime/arguments.cpp line 1183:
> 
>> 1181:   bool result         = true;
>> 1182: 
>> 1183:   char c = checked_cast<char>(getc(stream));
> 
> I think this only works if "char" is signed, because EOF is -1.  What I meant was:
> 
> int c0 = getc(stream);
> while (c0 != EOF ...) {
>   char c = checked_cast<char>(c0);
>   ...
>   c0 = getc(stream);

I don't see this as any cleaner than having the checked_cast in the place where we need to store a char.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289144572

From coleenp at openjdk.org  Wed Aug  9 20:23:30 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 20:23:30 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <9_wskfUjYqTIOG27mpDmO_ltC1RDl_GclltIsfZOQPw=.1447c996-764a-4d7a-96c8-2bf6e72bd85e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com>
 <pwj2_JKquMhJzbcqWQyDZ0qmFtd6UC8eejTehkXN6BI=.6f826144-1879-4d8c-b58c-2b9e693a95ee@github.com>
 <JJ1Fv8JlW6aZLT0vKA-EW5oBbeof9L-0PG38Nq6EplI=.6a18c20e-6a07-4cce-b138-521650ab9bf5@github.com>
 <9_wskfUjYqTIOG27mpDmO_ltC1RDl_GclltIsfZOQPw=.1447c996-764a-4d7a-96c8-2bf6e72bd85e@github.com>
Message-ID: <i4ZoXuf1HY3L4xGlbmUT7w63DhjK70ffq-VOme5WFAw=.e3faa6c0-b1dd-45eb-b8ab-b574ce8b3265@github.com>

On Wed, 9 Aug 2023 19:51:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> No, it works and is a bit better, so I made this change.
>
> I see error in some builds due to the EOF comparison though now that c is a char. I think Dean was suggesting doing the cast inside the loop.

That must have been the error I was seeing but couldn't remember.  I'm putting this back to the version I tested completely.  I don't see the point of adding another local variable here and doing the checked_cast<> until we need the char to be stored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289138719

From coleenp at openjdk.org  Wed Aug  9 20:45:00 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Aug 2023 20:45:00 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v7]
In-Reply-To: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
Message-ID: <iEZKebRuWXCzTAJhwLlrLEbLeRLLUtqx1EbtfLGJnVk=.19a66435-11d7-4b0b-a58e-40aed9783003@github.com>

> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
> 
> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>       |                                     ~~~~^~~
> 
> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Put arguments back to the tested version.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15177/files
  - new: https://git.openjdk.org/jdk/pull/15177/files/17eaec50..e254b2df

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

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

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

From dlong at openjdk.org  Wed Aug  9 20:48:59 2023
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Aug 2023 20:48:59 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6]
In-Reply-To: <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
Message-ID: <O9uoqIRyk1WAC2oerQH7GIN9KTVb170QaOo9xFQw3HE=.2c5547c5-9616-49aa-9271-10fe73796f96@github.com>

On Wed, 9 Aug 2023 15:43:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - put checked_cast around getc().
>  - put checked_cast around getc().

src/hotspot/share/runtime/objectMonitor.hpp line 238:

> 236:   //
> 237:   #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \
> 238:     ((in_bytes(ObjectMonitor::f ## _offset())) - (int)markWord::monitor_value)

Suggestion:

    ((in_bytes(ObjectMonitor::f ## _offset())) - (intptr_t)markWord::monitor_value)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289155570

From dholmes at openjdk.org  Wed Aug  9 22:35:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 9 Aug 2023 22:35:28 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v6]
In-Reply-To: <D_EpjNlhKVe3j24sxYotmOFOehi1YISaJHs8CRVZc3I=.d2f9e273-d79b-48ea-ad70-f18025b7d29c@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <D_EpjNlhKVe3j24sxYotmOFOehi1YISaJHs8CRVZc3I=.d2f9e273-d79b-48ea-ad70-f18025b7d29c@github.com>
Message-ID: <dV5_rXMwGs4I1Z0Dqn24sRTN3cshFBBqXE9kmtlMbPg=.76ef5156-e205-447c-bbbf-f24fbba4fe1e@github.com>

On Wed, 9 Aug 2023 14:54:04 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into wconv_jvm_options
>  - Matched with master.
>  - checked all usages of changed options.
>  - backslash aligned
>  - Review comments applied.
>  - Fixed intx->int for Wconversion warnings.

Updates look good.

Thanks

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

> 444:           "Enable the various ring buffer event logs")                      \
> 445:                                                                             \
> 446:   product(int, LogEventsBufferEntries, 20, DIAGNOSTIC,                      \

I was going to say this should keep its unsignedness but it is treated as an `int` everywhere anyway.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1570650769
PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1289260865

From coleenp at openjdk.org  Thu Aug 10 00:31:58 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Aug 2023 00:31:58 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6]
In-Reply-To: <O9uoqIRyk1WAC2oerQH7GIN9KTVb170QaOo9xFQw3HE=.2c5547c5-9616-49aa-9271-10fe73796f96@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
 <O9uoqIRyk1WAC2oerQH7GIN9KTVb170QaOo9xFQw3HE=.2c5547c5-9616-49aa-9271-10fe73796f96@github.com>
Message-ID: <J_jT1y1AjrbyJv0ZOrblDKIp4tQxvjR-KRHx3So-z_E=.79a9455e-a3ab-4a14-a902-f7b5f4935fd1@github.com>

On Wed, 9 Aug 2023 20:23:38 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - put checked_cast around getc().
>>  - put checked_cast around getc().
>
> src/hotspot/share/runtime/objectMonitor.hpp line 238:
> 
>> 236:   //
>> 237:   #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \
>> 238:     ((in_bytes(ObjectMonitor::f ## _offset())) - (int)markWord::monitor_value)
> 
> Suggestion:
> 
>     ((in_bytes(ObjectMonitor::f ## _offset())) - (intptr_t)markWord::monitor_value)

If this is intptr_t, it'll get a Wconversion warning on the uses that expect int.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289381020

From dlong at openjdk.org  Thu Aug 10 00:32:28 2023
From: dlong at openjdk.org (Dean Long)
Date: Thu, 10 Aug 2023 00:32:28 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6]
In-Reply-To: <J_jT1y1AjrbyJv0ZOrblDKIp4tQxvjR-KRHx3So-z_E=.79a9455e-a3ab-4a14-a902-f7b5f4935fd1@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
 <O9uoqIRyk1WAC2oerQH7GIN9KTVb170QaOo9xFQw3HE=.2c5547c5-9616-49aa-9271-10fe73796f96@github.com>
 <J_jT1y1AjrbyJv0ZOrblDKIp4tQxvjR-KRHx3So-z_E=.79a9455e-a3ab-4a14-a902-f7b5f4935fd1@github.com>
Message-ID: <-HOW_BRbv5A09m9N5cXRa6MunZHR-tYouRXZcZh6hpA=.9b6d3c82-22f2-4d8d-b75a-0b4517e0772b@github.com>

On Thu, 10 Aug 2023 00:13:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 238:
>> 
>>> 236:   //
>>> 237:   #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \
>>> 238:     ((in_bytes(ObjectMonitor::f ## _offset())) - (int)markWord::monitor_value)
>> 
>> Suggestion:
>> 
>>     ((in_bytes(ObjectMonitor::f ## _offset())) - (intptr_t)markWord::monitor_value)
>
> If this is intptr_t, it'll get a Wconversion warning on the uses that expect int.

OK, in that case checked_cast<int>() would be more correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289388423

From dholmes at openjdk.org  Thu Aug 10 01:17:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Aug 2023 01:17:28 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v6]
In-Reply-To: <D_EpjNlhKVe3j24sxYotmOFOehi1YISaJHs8CRVZc3I=.d2f9e273-d79b-48ea-ad70-f18025b7d29c@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <D_EpjNlhKVe3j24sxYotmOFOehi1YISaJHs8CRVZc3I=.d2f9e273-d79b-48ea-ad70-f18025b7d29c@github.com>
Message-ID: <T76xIn51T4UzUW5vDBF4dCyVZBQ-b17RcfikJX7wADA=.0a08d9d6-7c38-4a0c-ad18-29c18faded60@github.com>

On Wed, 9 Aug 2023 14:54:04 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into wconv_jvm_options
>  - Matched with master.
>  - checked all usages of changed options.
>  - backslash aligned
>  - Review comments applied.
>  - Fixed intx->int for Wconversion warnings.

Just noticed that `AllocatePrefetchStyle` should also be included in this.

Thanks

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1570828938

From coleenp at openjdk.org  Thu Aug 10 01:26:00 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Aug 2023 01:26:00 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v8]
In-Reply-To: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
Message-ID: <AtKiHqlTRXYfnniyiqriW-BHqngKuJ5h0NT7aZH7t6U=.c39478a9-d87d-4d9a-969e-bfa06eb14e08@github.com>

> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
> 
> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>       |                                     ~~~~^~~
> 
> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add a checked_cast.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15177/files
  - new: https://git.openjdk.org/jdk/pull/15177/files/e254b2df..0e21a929

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

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

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

From coleenp at openjdk.org  Thu Aug 10 01:29:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Aug 2023 01:29:28 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6]
In-Reply-To: <-HOW_BRbv5A09m9N5cXRa6MunZHR-tYouRXZcZh6hpA=.9b6d3c82-22f2-4d8d-b75a-0b4517e0772b@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <bdFBFRPXYuM6AbLTHYXzT-Rxn1YgeEZ0pc5GKtstnJY=.f920b31d-00b0-4fff-a5cc-2c2fc6129ff2@github.com>
 <O9uoqIRyk1WAC2oerQH7GIN9KTVb170QaOo9xFQw3HE=.2c5547c5-9616-49aa-9271-10fe73796f96@github.com>
 <J_jT1y1AjrbyJv0ZOrblDKIp4tQxvjR-KRHx3So-z_E=.79a9455e-a3ab-4a14-a902-f7b5f4935fd1@github.com>
 <-HOW_BRbv5A09m9N5cXRa6MunZHR-tYouRXZcZh6hpA=.9b6d3c82-22f2-4d8d-b75a-0b4517e0772b@github.com>
Message-ID: <i9JC_Xw7iPxtLB-StoDtdf17Ii7oReGdv0CQtxzUa_o=.3931e0ac-6a56-4da7-aa2b-936444b77a52@github.com>

On Thu, 10 Aug 2023 00:22:57 GMT, Dean Long <dlong at openjdk.org> wrote:

>> If this is intptr_t, it'll get a Wconversion warning on the uses that expect int.
>
> OK, in that case checked_cast<int>() would be more correct.

Ok.  Added a checked_cast.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289404613

From never at openjdk.org  Thu Aug 10 01:33:58 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 10 Aug 2023 01:33:58 GMT
Subject: RFR: 8314061: [JVMCI] DeoptimizeALot stress logic breaks deferred
 barriers
Message-ID: <n7-D0rZlT61bGwYach2tQKxJU6ylRHUrf5sy6Z_567E=.2074defa-f285-457a-8880-f980bc44cfe7@github.com>

JVMCIRuntime::new_array_common includes a little bit of stress logic that changes how it returns when DeoptimizeALot is set. This can cause it to bypass the call to SharedRuntime::on_slowpath_allocation_exit(current) which is where the deferred card mark logic lives. This can lead to random crashes of various kinds.

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

Commit messages:
 - 8314061: [JVMCI] DeoptimizeALot stress logic breaks deferred barriers

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

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

From coleenp at openjdk.org  Thu Aug 10 02:06:38 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Aug 2023 02:06:38 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v6]
In-Reply-To: <D_EpjNlhKVe3j24sxYotmOFOehi1YISaJHs8CRVZc3I=.d2f9e273-d79b-48ea-ad70-f18025b7d29c@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <D_EpjNlhKVe3j24sxYotmOFOehi1YISaJHs8CRVZc3I=.d2f9e273-d79b-48ea-ad70-f18025b7d29c@github.com>
Message-ID: <MMtNFVoyHptBJ3_LK8Dg9a0RS5M6EAZQ3F3v2YUZmSs=.e7cd6f63-4497-461d-900d-f36849311fde@github.com>

On Wed, 9 Aug 2023 14:54:04 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into wconv_jvm_options
>  - Matched with master.
>  - checked all usages of changed options.
>  - backslash aligned
>  - Review comments applied.
>  - Fixed intx->int for Wconversion warnings.

The criteria for choosing flags was whether they were causing -Wconversion warnings, which this one doesn't.   That said, it would be consistent to change this one since other AllocatePrefetch flags are changed.  There are likely many other flags that can be int not intx.  They can be changed in a different patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1672419781

From dlong at openjdk.org  Thu Aug 10 02:06:39 2023
From: dlong at openjdk.org (Dean Long)
Date: Thu, 10 Aug 2023 02:06:39 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v8]
In-Reply-To: <AtKiHqlTRXYfnniyiqriW-BHqngKuJ5h0NT7aZH7t6U=.c39478a9-d87d-4d9a-969e-bfa06eb14e08@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <AtKiHqlTRXYfnniyiqriW-BHqngKuJ5h0NT7aZH7t6U=.c39478a9-d87d-4d9a-969e-bfa06eb14e08@github.com>
Message-ID: <UgooUQUOjUzhyM3ko43Sc3UWsht7L4t96sAcyC6BDGE=.d9a5a943-0f19-4999-8886-32dad078e879@github.com>

On Thu, 10 Aug 2023 01:26:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a checked_cast.

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1570873804

From dholmes at openjdk.org  Thu Aug 10 05:08:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Aug 2023 05:08:29 GMT
Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32
 bits, for globals.hpp [v6]
In-Reply-To: <MMtNFVoyHptBJ3_LK8Dg9a0RS5M6EAZQ3F3v2YUZmSs=.e7cd6f63-4497-461d-900d-f36849311fde@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <D_EpjNlhKVe3j24sxYotmOFOehi1YISaJHs8CRVZc3I=.d2f9e273-d79b-48ea-ad70-f18025b7d29c@github.com>
 <MMtNFVoyHptBJ3_LK8Dg9a0RS5M6EAZQ3F3v2YUZmSs=.e7cd6f63-4497-461d-900d-f36849311fde@github.com>
Message-ID: <-JgChGRgQXuQ6_l0crjDUNVMcuAkwuP192MSGj8GB7A=.a75445ba-6177-4021-9030-0dfbcaa11443@github.com>

On Thu, 10 Aug 2023 01:50:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The criteria for choosing flags was whether they were causing -Wconversion warnings,

There is nothing in the PR or JBS to indicate this is the case. I assumed this would fix all oversized flags as the title indicates. If this is only a restricted subset perhaps the title and description should be updated to reflect that. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1672549503

From thartmann at openjdk.org  Thu Aug 10 05:50:59 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Aug 2023 05:50:59 GMT
Subject: RFR: 8314061: [JVMCI] DeoptimizeALot stress logic breaks deferred
 barriers
In-Reply-To: <n7-D0rZlT61bGwYach2tQKxJU6ylRHUrf5sy6Z_567E=.2074defa-f285-457a-8880-f980bc44cfe7@github.com>
References: <n7-D0rZlT61bGwYach2tQKxJU6ylRHUrf5sy6Z_567E=.2074defa-f285-457a-8880-f980bc44cfe7@github.com>
Message-ID: <YHpF6NkNdY0IZge2v34P2-VK6dQMwrKcIeduOh2BDVo=.ee9d0b6b-bb94-46da-ba82-0a31ae7cf001@github.com>

On Thu, 10 Aug 2023 01:06:35 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> JVMCIRuntime::new_array_common includes a little bit of stress logic that changes how it returns when DeoptimizeALot is set. This can cause it to bypass the call to SharedRuntime::on_slowpath_allocation_exit(current) which is where the deferred card mark logic lives. This can lead to random crashes of various kinds.

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15218#pullrequestreview-1571044722

From dholmes at openjdk.org  Thu Aug 10 06:34:59 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Aug 2023 06:34:59 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <i4ZoXuf1HY3L4xGlbmUT7w63DhjK70ffq-VOme5WFAw=.e3faa6c0-b1dd-45eb-b8ab-b574ce8b3265@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com>
 <pwj2_JKquMhJzbcqWQyDZ0qmFtd6UC8eejTehkXN6BI=.6f826144-1879-4d8c-b58c-2b9e693a95ee@github.com>
 <JJ1Fv8JlW6aZLT0vKA-EW5oBbeof9L-0PG38Nq6EplI=.6a18c20e-6a07-4cce-b138-521650ab9bf5@github.com>
 <9_wskfUjYqTIOG27mpDmO_ltC1RDl_GclltIsfZOQPw=.1447c996-764a-4d7a-96c8-2bf6e72bd85e@github.com>
 <i4ZoXuf1HY3L4xGlbmUT7w63DhjK70ffq-VOme5WFAw=.e3faa6c0-b1dd-45eb-b8ab-b574ce8b3265@github.com>
Message-ID: <FsDEBV81_QVwPgOiIwiS0yV9bJclF0migBuisbMvb1w=.a4026d79-b193-4e99-aee9-edc6b06e0ba2@github.com>

On Wed, 9 Aug 2023 20:06:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I see error in some builds due to the EOF comparison though now that c is a char. I think Dean was suggesting doing the cast inside the loop.
>
> That must have been the error I was seeing but couldn't remember.  I'm putting this back to the version I tested completely.  I don't see the point of adding another local variable here and doing the checked_cast<> until we need the char to be stored.

`getc` returns an int because it has to be able to return all valid char values plus EOF.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289606432

From dholmes at openjdk.org  Thu Aug 10 07:19:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Aug 2023 07:19:58 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
Message-ID: <CxVC5WgmBfo5QzugcEzakbqU3ftsdVBLJdphL-4aijM=.4246777b-b936-49c8-8f02-67fa3cfc30fc@github.com>

On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make bytecode.hpp index() functions return u2 not long.

src/hotspot/share/runtime/javaThread.hpp line 599:

> 597: 
> 598:   void inc_held_monitor_count(intx i = 1, bool jni = false);
> 599:   void dec_held_monitor_count(intx i = 1, bool jni = false);

Does the parameter type need to be changed? AFAICS we never increment by other than one in any case (and inc/dec imply one - else they should be add/sub).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289651653

From dholmes at openjdk.org  Thu Aug 10 07:18:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Aug 2023 07:18:07 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v8]
In-Reply-To: <AtKiHqlTRXYfnniyiqriW-BHqngKuJ5h0NT7aZH7t6U=.c39478a9-d87d-4d9a-969e-bfa06eb14e08@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <AtKiHqlTRXYfnniyiqriW-BHqngKuJ5h0NT7aZH7t6U=.c39478a9-d87d-4d9a-969e-bfa06eb14e08@github.com>
Message-ID: <yii0iZqIuJVUE379ERw1_xrPr8hYWbrJhsR-N7AyHUI=.eedeba06-7850-4e94-962d-fb65d2f9e707@github.com>

On Thu, 10 Aug 2023 01:26:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a checked_cast.

Overall seems okay. A couple of minor comments.

Thanks.

Clicked wrong button :)

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

PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1571161170
Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1571163699

From dnsimon at openjdk.org  Thu Aug 10 08:32:28 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 08:32:28 GMT
Subject: RFR: 8314061: [JVMCI] DeoptimizeALot stress logic breaks deferred
 barriers
In-Reply-To: <n7-D0rZlT61bGwYach2tQKxJU6ylRHUrf5sy6Z_567E=.2074defa-f285-457a-8880-f980bc44cfe7@github.com>
References: <n7-D0rZlT61bGwYach2tQKxJU6ylRHUrf5sy6Z_567E=.2074defa-f285-457a-8880-f980bc44cfe7@github.com>
Message-ID: <EtRKwfrgmHmu7QIoHxEH5yOA4h7y_413vIctnk3nl0M=.9eec44be-3a9b-46af-a405-a3db05d118c0@github.com>

On Thu, 10 Aug 2023 01:06:35 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> JVMCIRuntime::new_array_common includes a little bit of stress logic that changes how it returns when DeoptimizeALot is set. This can cause it to bypass the call to SharedRuntime::on_slowpath_allocation_exit(current) which is where the deferred card mark logic lives. This can lead to random crashes of various kinds.

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15218#pullrequestreview-1571285872

From dnsimon at openjdk.org  Thu Aug 10 08:36:28 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 08:36:28 GMT
Subject: RFR: 8313421: [JVMCI] avoid locking class loader in
 CompilerToVM.lookupType [v2]
In-Reply-To: <5y-ZYjEZQrFUVuAvDQTWVGb4hOtBVzzpnWoKmK_-GAY=.a0c10c2e-3a7c-418f-a71c-ed86ecda7eaa@github.com>
References: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>
 <5y-ZYjEZQrFUVuAvDQTWVGb4hOtBVzzpnWoKmK_-GAY=.a0c10c2e-3a7c-418f-a71c-ed86ecda7eaa@github.com>
Message-ID: <_dnAOEYiYQA_ktAwKozDYzv5c-UT1ao49Ot05SVS08U=.42892582-b7c5-4223-b5b7-06b3de8d230d@github.com>

On Tue, 8 Aug 2023 13:54:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR removes the need to lock the system class loader when converting Class instances for boot and platform classes to ResolvedJavaType objects. Not only is the system class loader a suboptimal loader for resolving these classes but locking it can cause deadlock in some JDK tests (e.g. `test/jdk/java/lang/System/LoggerFinder/`) when run with `-Xcomp`. For example, a thread that holds the system class loader lock and triggers a blocking compilation will deadlock with the compiler thread servicing the compilation if the compilation requires calling `CompilerToVM.lookupType` (which most compilations do).
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8313421
>  - avoid locking class loader in CompilerToVM.lookupType (JDK-8313421)

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/15128#issuecomment-1672770989

From dnsimon at openjdk.org  Thu Aug 10 08:36:58 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 08:36:58 GMT
Subject: Integrated: 8313421: [JVMCI] avoid locking class loader in
 CompilerToVM.lookupType
In-Reply-To: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>
References: <zCsz86HUyZo2ztjzpCtxWqAfWCtqUoMJJ4DUJwe_38c=.8d752d09-1e2e-4a68-a27b-2a3762dc3d0c@github.com>
Message-ID: <CgoEuliG4PZS1gY6FEcd-IYpofTYOpRrQRNUx-4Ju5c=.3fe01ada-e6cc-4c54-a8fa-0821ad8e0149@github.com>

On Wed, 2 Aug 2023 20:33:49 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR removes the need to lock the system class loader when converting Class instances for boot and platform classes to ResolvedJavaType objects. Not only is the system class loader a suboptimal loader for resolving these classes but locking it can cause deadlock in some JDK tests (e.g. `test/jdk/java/lang/System/LoggerFinder/`) when run with `-Xcomp`. For example, a thread that holds the system class loader lock and triggers a blocking compilation will deadlock with the compiler thread servicing the compilation if the compilation requires calling `CompilerToVM.lookupType` (which most compilations do).

This pull request has now been integrated.

Changeset: 83adaf54
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83adaf5477d1aa0128079a60be8847319dbadccc
Stats:     93 lines in 8 files changed: 41 ins; 19 del; 33 mod

8313421: [JVMCI] avoid locking class loader in CompilerToVM.lookupType

Reviewed-by: never, thartmann

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

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

From coleenp at openjdk.org  Thu Aug 10 12:07:59 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Aug 2023 12:07:59 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v8]
In-Reply-To: <AtKiHqlTRXYfnniyiqriW-BHqngKuJ5h0NT7aZH7t6U=.c39478a9-d87d-4d9a-969e-bfa06eb14e08@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <AtKiHqlTRXYfnniyiqriW-BHqngKuJ5h0NT7aZH7t6U=.c39478a9-d87d-4d9a-969e-bfa06eb14e08@github.com>
Message-ID: <vWdJFmiFzzN8GRmY_dHUsmwiECepUuvSreWNHYIE7mw=.612f4935-098a-4754-9fe4-b07912fc176a@github.com>

On Thu, 10 Aug 2023 01:26:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
>> 
>> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>>       |                                     ~~~~^~~
>> 
>> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a checked_cast.

Thanks for the reviews, Patricio, Dean and David. I believe I addressed all the comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/15177#issuecomment-1673078895

From coleenp at openjdk.org  Thu Aug 10 12:09:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Aug 2023 12:09:29 GMT
Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2]
In-Reply-To: <CxVC5WgmBfo5QzugcEzakbqU3ftsdVBLJdphL-4aijM=.4246777b-b936-49c8-8f02-67fa3cfc30fc@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
 <icTh3mwb4Q5fyl_FNS9GxKvPV_HvKiRWJdkdnEyrIk8=.29af2d59-0248-46ef-8e0b-91da41baf39a@github.com>
 <CxVC5WgmBfo5QzugcEzakbqU3ftsdVBLJdphL-4aijM=.4246777b-b936-49c8-8f02-67fa3cfc30fc@github.com>
Message-ID: <2EPJzGnsBYxehzOGMWH4KkKzh6XMRNioQvM8ov21d-g=.42af4d3e-ed1b-4de8-b844-62893e0982ae@github.com>

On Thu, 10 Aug 2023 07:02:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make bytecode.hpp index() functions return u2 not long.
>
> src/hotspot/share/runtime/javaThread.hpp line 599:
> 
>> 597: 
>> 598:   void inc_held_monitor_count(intx i = 1, bool jni = false);
>> 599:   void dec_held_monitor_count(intx i = 1, bool jni = false);
> 
> Does the parameter type need to be changed? AFAICS we never increment by other than one in any case (and inc/dec imply one - else they should be add/sub).

Yes, the parameter type needed to be changed because:

  void do_monitor(ObjectMonitor* mid) {
    intx rec = mid->complete_exit(_thread);
    _thread->dec_held_monitor_count(rec + 1);
  }


In general, I only widen things when there's a warning produced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1290010985

From thartmann at openjdk.org  Thu Aug 10 12:21:10 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Aug 2023 12:21:10 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <SeKm9x0yMf7J7bX2dvS0IPgoAeGo0dIV9kGAGiyY-4M=.053e3dda-6af6-452a-a825-ed864b34ca62@github.com>

On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15198#pullrequestreview-1571741510

From dnsimon at openjdk.org  Thu Aug 10 12:22:00 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 12:22:00 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <CwhUQ6_eWDj6wN7hiyDGM8bVNcS0wdvPykO5kwgxBzI=.55852b16-2fce-4d88-98dc-31ad270d0230@github.com>

On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

src/hotspot/share/jvmci/jvmciEnv.cpp line 472:

> 470:                             vmSymbols::encodeThrowable_name(),
> 471:                             vmSymbols::encodeThrowable_signature(), &jargs, THREAD);
> 472:     if (handle_pending_exception(THREAD, buffer, buffer_size)) {

This is the actual bug fix: handle any exception occurring in the Java upcall.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15198#discussion_r1290014253

From coleenp at openjdk.org  Thu Aug 10 12:26:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Aug 2023 12:26:28 GMT
Subject: Integrated: 8313882: Fix -Wconversion warnings in runtime code
In-Reply-To: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
References: <OmbHjs7St3HuC5gH5-GgMa2rzE1YpPLNPEMofbxWMk4=.90fc3286-800a-4f22-b859-cf2cbb78994e@github.com>
Message-ID: <8fsAx47Xb01FdWOZXnrWwgYx-29Kv3iPkKxJcC0rR3c=.1b4a33c6-cdac-4929-93c7-edec59186dec@github.com>

On Mon, 7 Aug 2023 12:57:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Here are fixes to silence -Wconversion warnings in runtime code.  Use direct cast for 64 bit int to double, otherwise default to checked_cast<>.  I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this.
> 
> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion]
>  1802 |     _thread->dec_held_monitor_count(rec + 1);
>       |                                     ~~~~^~~
> 
> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms.

This pull request has now been integrated.

Changeset: f47767ff
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f47767ffef29c777e2da0262fa3299564d59f461
Stats:     138 lines in 26 files changed: 3 ins; 9 del; 126 mod

8313882: Fix -Wconversion warnings in runtime code

Reviewed-by: pchilanomate, dlong, dholmes

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

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

From dnsimon at openjdk.org  Thu Aug 10 13:56:37 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 13:56:37 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit> [v2]
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

Doug Simon has updated the pull request incrementally with two additional commits since the last revision:

 - guard test-only code with ASSERT instead of !PRODUCT
 - omit test-only code in product build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15198/files
  - new: https://git.openjdk.org/jdk/pull/15198/files/529258a8..f160cb80

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

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

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

From thartmann at openjdk.org  Thu Aug 10 13:56:38 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Aug 2023 13:56:38 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit> [v2]
In-Reply-To: <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
 <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>
Message-ID: <de-iz_yAckG9RKnGOKM2KSFYgdPiqorOi6E07x3eonw=.c4889c70-8c16-4c61-b10c-92d39324f998@github.com>

On Thu, 10 Aug 2023 13:41:05 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
>> 
>> java.lang.OutOfMemoryError: Metaspace
>>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
>> 
>> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
>> 
>> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - guard test-only code with ASSERT instead of !PRODUCT
>  - omit test-only code in product build

Still looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15198#pullrequestreview-1571929038

From yzheng at openjdk.org  Thu Aug 10 14:41:09 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 10 Aug 2023 14:41:09 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v3]
In-Reply-To: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
Message-ID: <Rk8AYzB3h-1cJy3_2CDkJ9I8aMkJrFdjQozTYNMhX6s=.de6c7e70-0901-4646-bc06-49f419ae3297@github.com>

> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  avoid duplicating cpu feature checks.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15133/files
  - new: https://git.openjdk.org/jdk/pull/15133/files/fba23164..c6e6dc64

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

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

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

From azafari at openjdk.org  Thu Aug 10 14:45:30 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 10 Aug 2023 14:45:30 GMT
Subject: RFR: Change JVM options with small ranges that get -Wconversion
 warnings to 32 bits [v7]
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  Fixed a missed option.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15164/files
  - new: https://git.openjdk.org/jdk/pull/15164/files/2e25bbf8..51df0d35

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

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

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

From yzheng at openjdk.org  Thu Aug 10 15:00:59 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 10 Aug 2023 15:00:59 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v4]
In-Reply-To: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
Message-ID: <IMYFwDHabB65TV-u-Rndq7q_jOKw7SLvcPjs6G64toU=.0ef8ad5b-7fd7-49e9-977e-153f09c145b9@github.com>

> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15133/files
  - new: https://git.openjdk.org/jdk/pull/15133/files/c6e6dc64..1d2b83e6

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

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

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

From yzheng at openjdk.org  Thu Aug 10 15:04:58 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 10 Aug 2023 15:04:58 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v2]
In-Reply-To: <Rtnwno_fbTT9f_pkahS4c0QGMSW7tSbCbNpZ5L0t9JE=.4ebbfdc1-8acd-42f9-9824-7f5898233af8@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
 <Rtnwno_fbTT9f_pkahS4c0QGMSW7tSbCbNpZ5L0t9JE=.4ebbfdc1-8acd-42f9-9824-7f5898233af8@github.com>
Message-ID: <9WeBz8r5aL5xW5HDjw-za0NOTMZU7VEgI0PadSri5aU=.3c958061-4355-4ccf-b3ea-9895bb6dd68a@github.com>

On Wed, 9 Aug 2023 08:46:36 GMT, Dean Long <dlong at openjdk.org> wrote:

> I don't having the same logic in two places, because then those two places need to be kept in sync. Either the stubs should be generated based on is_intrinsic_supported(), or is_intrinsic_supported() should check if the stub was generated.

I have dropped the redundant CPU feature checks, and for those intrinsics with stubs, I tested if the stub pointer is nullptr in `C2Compiler::is_intrinsic_supported`

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

PR Comment: https://git.openjdk.org/jdk/pull/15133#issuecomment-1673331114

From coleenp at openjdk.org  Thu Aug 10 15:05:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Aug 2023 15:05:29 GMT
Subject: RFR: Change JVM options with small ranges that get -Wconversion
 warnings to 32 bits [v7]
In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
Message-ID: <avOtk3XSffoLYAX-DTH5l5df9T5ew8DlQRE9toh8qcs=.c846fbef-7072-42fe-b9f2-25d5941d3667@github.com>

On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a missed option.

Still good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1572120640

From iklam at openjdk.org  Thu Aug 10 16:20:06 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 10 Aug 2023 16:20:06 GMT
Subject: RFR: 8308850: Change JVM options with small ranges that get
 -Wconversion warnings to 32 bits [v7]
In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
Message-ID: <yM6Q9a6blhdcJNTLJjEuDHnme65FKqDG-frrjQyAQMk=.5746bae7-445e-47b0-903c-89ca041f47f9@github.com>

On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a missed option.

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 261:

> 259:   do_int_flag(AllocatePrefetchLines)                                       \
> 260:   do_int_flag(AllocatePrefetchStepSize)                                    \
> 261:   do_int_flag(AllocatePrefetchStyle)                                       \

Why is AllocatePrefetchInstr not changed? It seems to use 0-3 only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1290366462

From never at openjdk.org  Thu Aug 10 16:53:28 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 10 Aug 2023 16:53:28 GMT
Subject: RFR: 8314061: [JVMCI] DeoptimizeALot stress logic breaks deferred
 barriers
In-Reply-To: <n7-D0rZlT61bGwYach2tQKxJU6ylRHUrf5sy6Z_567E=.2074defa-f285-457a-8880-f980bc44cfe7@github.com>
References: <n7-D0rZlT61bGwYach2tQKxJU6ylRHUrf5sy6Z_567E=.2074defa-f285-457a-8880-f980bc44cfe7@github.com>
Message-ID: <RWwSlBdAesEYpLsaOAVaVO7v3iPmYVqfPGa4pt6CUEI=.060cf655-0d17-4821-aa8a-796dd43c3994@github.com>

On Thu, 10 Aug 2023 01:06:35 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> JVMCIRuntime::new_array_common includes a little bit of stress logic that changes how it returns when DeoptimizeALot is set. This can cause it to bypass the call to SharedRuntime::on_slowpath_allocation_exit(current) which is where the deferred card mark logic lives. This can lead to random crashes of various kinds.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/15218#issuecomment-1673557828

From never at openjdk.org  Thu Aug 10 16:53:29 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Thu, 10 Aug 2023 16:53:29 GMT
Subject: Integrated: 8314061: [JVMCI] DeoptimizeALot stress logic breaks
 deferred barriers
In-Reply-To: <n7-D0rZlT61bGwYach2tQKxJU6ylRHUrf5sy6Z_567E=.2074defa-f285-457a-8880-f980bc44cfe7@github.com>
References: <n7-D0rZlT61bGwYach2tQKxJU6ylRHUrf5sy6Z_567E=.2074defa-f285-457a-8880-f980bc44cfe7@github.com>
Message-ID: <wq1l3wqr2g997mlsCulTrFk9gxnS0qqprjIW-gPA7AA=.ddfc1963-3f75-4fc0-a7d4-ca965034f149@github.com>

On Thu, 10 Aug 2023 01:06:35 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> JVMCIRuntime::new_array_common includes a little bit of stress logic that changes how it returns when DeoptimizeALot is set. This can cause it to bypass the call to SharedRuntime::on_slowpath_allocation_exit(current) which is where the deferred card mark logic lives. This can lead to random crashes of various kinds.

This pull request has now been integrated.

Changeset: 1875b287
Author:    Tom Rodriguez <never at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1875b2872baa566fa11f92006c8eba7642267213
Stats:     4 lines in 1 file changed: 2 ins; 1 del; 1 mod

8314061: [JVMCI] DeoptimizeALot stress logic breaks deferred barriers

Reviewed-by: thartmann, dnsimon

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

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

From kvn at openjdk.org  Thu Aug 10 17:05:58 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 10 Aug 2023 17:05:58 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v4]
In-Reply-To: <hjTFRN-GDyJIhdj9ELNc_DgxgCE61lOzC2FWMt7m8Fo=.84203ec2-82ad-470c-95d2-b6022c5b7cf7@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
 <iq5w7kT8631qt8NIlMpcB4LnTnn1YH3hCk4Kk0QcBc8=.f29c1ec8-3ea9-47cf-8af2-eda1f0aa85f3@github.com>
 <hjTFRN-GDyJIhdj9ELNc_DgxgCE61lOzC2FWMt7m8Fo=.84203ec2-82ad-470c-95d2-b6022c5b7cf7@github.com>
Message-ID: <4i5IXOTKEPmaWHmsb5lvsdT-7psgFlUKcs6isBM9rXE=.dbf6919a-b786-4a28-9c84-00793f156647@github.com>

On Thu, 10 Aug 2023 16:55:24 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.hpp line 689:
>> 
>>> 687:   static bool supports_avxonly()      { return ((supports_avx2() || supports_avx()) && !supports_evex()); }
>>> 688:   static bool supports_sha()          { return (_features & CPU_SHA) != 0; }
>>> 689:   static bool supports_fma()          { return (_features & CPU_FMA) != 0 && supports_avx(); }
>> 
>> https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/vm_version_x86.cpp#L1154-L1158
>> implies fma intrinsic can be used without AVX
>
> https://bugs.openjdk.org/browse/JDK-8181616  added support_avx() check because new Fma vectorization needs AVX: https://cr.openjdk.org/~vdeshpande/8181616/webrev.01/
> Then we hit bug https://bugs.openjdk.org/browse/JDK-8182114 and bandaid it by restoring UseSSE check.
> That change came before 8296168 which switch off UseAVX if UseSSE < 4:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L908
> 
> This FMA check happens after UseSSE and UseAVX are set. I suggest to remove UseSSE check here instead and keep support_avx().

Saying that. You may remove support_avx() here but you need to add it to assembler vector instructions which have only support_fma() check now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1290430146

From kvn at openjdk.org  Thu Aug 10 17:05:29 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 10 Aug 2023 17:05:29 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v4]
In-Reply-To: <iq5w7kT8631qt8NIlMpcB4LnTnn1YH3hCk4Kk0QcBc8=.f29c1ec8-3ea9-47cf-8af2-eda1f0aa85f3@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
 <iq5w7kT8631qt8NIlMpcB4LnTnn1YH3hCk4Kk0QcBc8=.f29c1ec8-3ea9-47cf-8af2-eda1f0aa85f3@github.com>
Message-ID: <hjTFRN-GDyJIhdj9ELNc_DgxgCE61lOzC2FWMt7m8Fo=.84203ec2-82ad-470c-95d2-b6022c5b7cf7@github.com>

On Thu, 3 Aug 2023 07:09:18 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup.
>
> src/hotspot/cpu/x86/vm_version_x86.hpp line 689:
> 
>> 687:   static bool supports_avxonly()      { return ((supports_avx2() || supports_avx()) && !supports_evex()); }
>> 688:   static bool supports_sha()          { return (_features & CPU_SHA) != 0; }
>> 689:   static bool supports_fma()          { return (_features & CPU_FMA) != 0 && supports_avx(); }
> 
> https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/vm_version_x86.cpp#L1154-L1158
> implies fma intrinsic can be used without AVX

https://bugs.openjdk.org/browse/JDK-8181616  added support_avx() check because new Fma vectorization needs AVX: https://cr.openjdk.org/~vdeshpande/8181616/webrev.01/
Then we hit bug https://bugs.openjdk.org/browse/JDK-8182114 and bandaid it by restoring UseSSE check.
That change came before 8296168 which switch off UseAVX if UseSSE < 4:
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L908

This FMA check happens after UseSSE and UseAVX are set. I suggest to remove UseSSE check here instead and keep support_avx().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1290424028

From kvn at openjdk.org  Thu Aug 10 17:07:28 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 10 Aug 2023 17:07:28 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v2]
In-Reply-To: <iq5w7kT8631qt8NIlMpcB4LnTnn1YH3hCk4Kk0QcBc8=.f29c1ec8-3ea9-47cf-8af2-eda1f0aa85f3@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
 <iq5w7kT8631qt8NIlMpcB4LnTnn1YH3hCk4Kk0QcBc8=.f29c1ec8-3ea9-47cf-8af2-eda1f0aa85f3@github.com>
Message-ID: <lnmjjmS6Ip6-mHbT_Mj2b9NXWF0h_eo2a1Ym2MCkeRU=.44d894bc-72ca-4530-b4a3-0673ef42674f@github.com>

On Thu, 3 Aug 2023 07:07:02 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update is_intrinsic_supported for _dcopySign,_fcopySign.
>
> src/hotspot/share/opto/c2compiler.cpp line 237:
> 
>> 235:   case vmIntrinsics::_electronicCodeBook_decryptAESCrypt:
>> 236:     if (StubRoutines::electronicCodeBook_decryptAESCrypt() == nullptr) return false;
>> 237:     break;
> 
> These two intrinsics were marked as supported on non-x86 platforms where the underlying stubs are not generated

good catch

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1290397831

From coleenp at openjdk.org  Thu Aug 10 17:20:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 10 Aug 2023 17:20:29 GMT
Subject: RFR: 8308850: Change JVM options with small ranges that get
 -Wconversion warnings to 32 bits [v7]
In-Reply-To: <yM6Q9a6blhdcJNTLJjEuDHnme65FKqDG-frrjQyAQMk=.5746bae7-445e-47b0-903c-89ca041f47f9@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
 <yM6Q9a6blhdcJNTLJjEuDHnme65FKqDG-frrjQyAQMk=.5746bae7-445e-47b0-903c-89ca041f47f9@github.com>
Message-ID: <M2HYuWX5pR2H5a_T_AuZJsAYda8Bg6k36ra6ZTsAKpM=.abbbdd6a-63ce-4152-9665-466a68833557@github.com>

On Thu, 10 Aug 2023 16:07:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed a missed option.
>
> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 261:
> 
>> 259:   do_int_flag(AllocatePrefetchLines)                                       \
>> 260:   do_int_flag(AllocatePrefetchStepSize)                                    \
>> 261:   do_int_flag(AllocatePrefetchStyle)                                       \
> 
> Why is AllocatePrefetchInstr not changed? It seems to use 0-3 only.

Looks like from the constraints, it's allowed to be max_intx on some platforms, so changing this would be a functional change.

JVMFlag::Error AllocatePrefetchInstrConstraintFunc(intx value, bool verbose) {
  intx max_value = max_intx;
#if defined(X86)
  max_value = 3;
#endif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1290427987

From iklam at openjdk.org  Thu Aug 10 18:07:28 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 10 Aug 2023 18:07:28 GMT
Subject: RFR: 8308850: Change JVM options with small ranges that get
 -Wconversion warnings to 32 bits [v7]
In-Reply-To: <M2HYuWX5pR2H5a_T_AuZJsAYda8Bg6k36ra6ZTsAKpM=.abbbdd6a-63ce-4152-9665-466a68833557@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
 <yM6Q9a6blhdcJNTLJjEuDHnme65FKqDG-frrjQyAQMk=.5746bae7-445e-47b0-903c-89ca041f47f9@github.com>
 <M2HYuWX5pR2H5a_T_AuZJsAYda8Bg6k36ra6ZTsAKpM=.abbbdd6a-63ce-4152-9665-466a68833557@github.com>
Message-ID: <CyL_HjwImbXT77f95Gup1FXExSKrRGqre6EVRD74Y7o=.c6135478-41cb-4f9a-a5df-aa5ec2421015@github.com>

On Thu, 10 Aug 2023 16:59:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 261:
>> 
>>> 259:   do_int_flag(AllocatePrefetchLines)                                       \
>>> 260:   do_int_flag(AllocatePrefetchStepSize)                                    \
>>> 261:   do_int_flag(AllocatePrefetchStyle)                                       \
>> 
>> Why is AllocatePrefetchInstr not changed? It seems to use 0-3 only.
>
> Looks like from the constraints, it's allowed to be max_intx on some platforms, so changing this would be a functional change.
> 
> JVMFlag::Error AllocatePrefetchInstrConstraintFunc(intx value, bool verbose) {
>   intx max_value = max_intx;
> #if defined(X86)
>   max_value = 3;
> #endif

OK, that sounds reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1290492755

From dnsimon at openjdk.org  Thu Aug 10 19:10:29 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 19:10:29 GMT
Subject: Integrated: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <PIp8kU5nQNbvEdSKGRqiv0U-qEePi206figumm-bqQU=.405ebd4b-16b1-4841-bd72-68b005a49e19@github.com>

On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

This pull request has now been integrated.

Changeset: 6f5c903d
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f5c903d10aa5f7ff979a79f121609c167f88eff
Stats:     60 lines in 6 files changed: 58 ins; 1 del; 1 mod

8313899: JVMCI exception Translation can fail in TranslatedException.<clinit>

Reviewed-by: never, thartmann

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

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

From dnsimon at openjdk.org  Thu Aug 10 19:10:28 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 19:10:28 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit> [v2]
In-Reply-To: <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
 <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>
Message-ID: <smBcTsOKOTRQRtg482AUmk9IMj0uRQuMVA-bpTqQ1ac=.d61e1fcf-35a1-4707-b7d1-23a0ad07d467@github.com>

On Thu, 10 Aug 2023 13:56:37 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
>> 
>> java.lang.OutOfMemoryError: Metaspace
>>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
>> 
>> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
>> 
>> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - guard test-only code with ASSERT instead of !PRODUCT
>  - omit test-only code in product build

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/15198#issuecomment-1673739930

From dholmes at openjdk.org  Fri Aug 11 01:30:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 11 Aug 2023 01:30:28 GMT
Subject: RFR: 8308850: Change JVM options with small ranges that get
 -Wconversion warnings to 32 bits [v7]
In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
Message-ID: <TrH-mOqrVMtOcLCWTAI62uPbyi3zdMtTFoU3vEbLvSk=.173034d7-d01c-4067-8894-6f44b5caa93d@github.com>

On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a missed option.

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1572903552

From iklam at openjdk.org  Fri Aug 11 01:47:28 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 11 Aug 2023 01:47:28 GMT
Subject: RFR: 8314078: HotSpotConstantPool.lookupField() asserts due to field
 changes in ConstantPool.cpp
Message-ID: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>

This PR updates Java code in JVMCI to match the C code changes in [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996) that modified the constant pool layout. Essentially, the indices after a getfield/putfield/getstatic/putstatic bytecode is no longer a CpCacheIndex, but an index for `ConstantPool::resolved_field_entry_at(int field_index)`.

The assertion (and subsequent crash) happen only in debug builds. Out of pure luck, in product build JVMCI produces the correct output even after [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996), although the code was doing the wrong thing.

This PR has (so far) two commits:

- 6527e67b1832087d180d2b50b65aaeca2e244c28 The actual functional change to use the `rawIndex` that follows a field bytecode.
- c322b8e71d4d9e33bd065e64420101010f9127fc Fixed incorrectly named parameters and variables in the JVMCI code and JavaDoc. In most cases, `cpi` needs to be changed to `rawIndex` to reflect the correct type of the index.

To help reviewing, I am limiting the renaming to just those affected by the field changes (without the renames, it's hard to validate that I am actually doing the right thing).

There are still some cases of `cpi` that need to be changed to `rawIndex`. I will fix those in a separate RFE. E.g. in ConstantPool.java:


default JavaMethod lookupMethod(int cpi, int opcode) {
    return lookupMethod(cpi, opcode, null);
}

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

Commit messages:
 - (no actual code changes) Fixed variable names and javadoc so that changes in this PR are consistent
 - 8314078: HotSpotConstantPool.lookupField() asserts due to field changes in ConstantPool.cpp

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

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

From dlong at openjdk.org  Fri Aug 11 07:04:29 2023
From: dlong at openjdk.org (Dean Long)
Date: Fri, 11 Aug 2023 07:04:29 GMT
Subject: RFR: 8308850: Change JVM options with small ranges that get
 -Wconversion warnings to 32 bits [v7]
In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
Message-ID: <JDkdDQHuQN3OLe6iPINFV1oW3vpg44xYmfmTkfpXrWc=.3db8d00b-4c41-4735-876e-480695d448ca@github.com>

On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a missed option.

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1573080897

From tschatzl at openjdk.org  Fri Aug 11 07:34:59 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Aug 2023 07:34:59 GMT
Subject: RFR: 8308850: Change JVM options with small ranges that get
 -Wconversion warnings to 32 bits [v7]
In-Reply-To: <CyL_HjwImbXT77f95Gup1FXExSKrRGqre6EVRD74Y7o=.c6135478-41cb-4f9a-a5df-aa5ec2421015@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
 <yM6Q9a6blhdcJNTLJjEuDHnme65FKqDG-frrjQyAQMk=.5746bae7-445e-47b0-903c-89ca041f47f9@github.com>
 <M2HYuWX5pR2H5a_T_AuZJsAYda8Bg6k36ra6ZTsAKpM=.abbbdd6a-63ce-4152-9665-466a68833557@github.com>
 <CyL_HjwImbXT77f95Gup1FXExSKrRGqre6EVRD74Y7o=.c6135478-41cb-4f9a-a5df-aa5ec2421015@github.com>
Message-ID: <mymvQQc7yzGdKn8xX1pO6cjnsOpxNznwMG85uUTpTq8=.b97039bc-31f7-4257-bb55-41e6faaa6115@github.com>

On Thu, 10 Aug 2023 17:57:12 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Looks like from the constraints, it's allowed to be max_intx on some platforms, so changing this would be a functional change.
>> 
>> JVMFlag::Error AllocatePrefetchInstrConstraintFunc(intx value, bool verbose) {
>>   intx max_value = max_intx;
>> #if defined(X86)
>>   max_value = 3;
>> #endif
>
> OK, that sounds reasonable.

Fwiw, only x86 uses `AllocatePrefetchInstr`. Other platforms never use it, so its value for those is meaningless.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1290976345

From dnsimon at openjdk.org  Fri Aug 11 12:27:30 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 11 Aug 2023 12:27:30 GMT
Subject: RFR: 8314078: HotSpotConstantPool.lookupField() asserts due to
 field changes in ConstantPool.cpp
In-Reply-To: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
References: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
Message-ID: <COsFshpDK4rww7ujq5yfQ4dKpDJtSpcV31fJYrPTbTw=.d2f97b9f-2d60-41ef-be41-b1b291fe3642@github.com>

On Fri, 11 Aug 2023 01:15:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR updates Java code in JVMCI to match the C code changes in [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996) that modified the constant pool layout. Essentially, the indices after a getfield/putfield/getstatic/putstatic bytecode is no longer a CpCacheIndex, but an index for `ConstantPool::resolved_field_entry_at(int field_index)`.
> 
> The assertion (and subsequent crash) happen only in debug builds. Out of pure luck, in product build JVMCI produces the correct output even after [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996), although the code was doing the wrong thing.
> 
> This PR has (so far) two commits:
> 
> - 6527e67b1832087d180d2b50b65aaeca2e244c28 The actual functional change to use the `rawIndex` that follows a field bytecode.
> - c322b8e71d4d9e33bd065e64420101010f9127fc Fixed incorrectly named parameters and variables in the JVMCI code and JavaDoc. In most cases, `cpi` needs to be changed to `rawIndex` to reflect the correct type of the index.
> 
> To help reviewing, I am limiting the renaming to just those affected by the field changes (without the renames, it's hard to validate that I am actually doing the right thing).
> 
> There are still some cases of `cpi` that need to be changed to `rawIndex`. I will fix those in a separate RFE. E.g. in ConstantPool.java:
> 
> 
> default JavaMethod lookupMethod(int cpi, int opcode) {
>     return lookupMethod(cpi, opcode, null);
> }

Marked as reviewed by dnsimon (Reviewer).

Thanks for doing this Ioi.

In this PR or the follow-up renaming RFE, could you please add a "decoder ring" comment to the javadoc for ConstantPool. An incomplete example:

 * The following terminology is used when indexing a constant pool entry:
 * <ul>
 * <li>rawIndex - index in the bytecode stream after the opcode (could be rewritten for some bytecodes)</li>
 * <li>cpi - the class file constant pool index</li>
 * <li>cpci - a constant pool cache index</li>
 * </ul>

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

PR Review: https://git.openjdk.org/jdk/pull/15237#pullrequestreview-1573540144
PR Comment: https://git.openjdk.org/jdk/pull/15237#issuecomment-1674643799

From yzheng at openjdk.org  Fri Aug 11 15:20:59 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Fri, 11 Aug 2023 15:20:59 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v5]
In-Reply-To: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
Message-ID: <gfWDSPQqqRmnEfPA3F3ioavn3bJy9ETrLD_jCrCmNXs=.8597df33-b18c-4a38-9c14-f7a5b4ce41b4@github.com>

> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.

Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:

  revert change in supports_fma.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15133/files
  - new: https://git.openjdk.org/jdk/pull/15133/files/1d2b83e6..028aaf5a

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

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

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

From yzheng at openjdk.org  Fri Aug 11 15:22:58 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Fri, 11 Aug 2023 15:22:58 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v5]
In-Reply-To: <4i5IXOTKEPmaWHmsb5lvsdT-7psgFlUKcs6isBM9rXE=.dbf6919a-b786-4a28-9c84-00793f156647@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
 <iq5w7kT8631qt8NIlMpcB4LnTnn1YH3hCk4Kk0QcBc8=.f29c1ec8-3ea9-47cf-8af2-eda1f0aa85f3@github.com>
 <hjTFRN-GDyJIhdj9ELNc_DgxgCE61lOzC2FWMt7m8Fo=.84203ec2-82ad-470c-95d2-b6022c5b7cf7@github.com>
 <4i5IXOTKEPmaWHmsb5lvsdT-7psgFlUKcs6isBM9rXE=.dbf6919a-b786-4a28-9c84-00793f156647@github.com>
Message-ID: <REYO8ARI2Gmb_KUZSd6FynyqPSkBxhho1bu1t9jx7lc=.692442d1-8ce5-4f35-804d-39b0bffb1928@github.com>

On Thu, 10 Aug 2023 17:00:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8181616  added support_avx() check because new Fma vectorization needs AVX: https://cr.openjdk.org/~vdeshpande/8181616/webrev.01/
>> Then we hit bug https://bugs.openjdk.org/browse/JDK-8182114 and bandaid it by restoring UseSSE check.
>> That change came before 8296168 which switch off UseAVX if UseSSE < 4:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L908
>> 
>> This FMA check happens after UseSSE and UseAVX are set. I suggest to remove UseSSE check here instead and keep support_avx().
>
> Saying that. You may remove support_avx() here but you need to add it to assembler vector instructions which have only support_fma() check now.

Thanks for the references! I have reverted this change and will adjust the Graal intrinsic accordingly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1291448160

From coleenp at openjdk.org  Fri Aug 11 16:10:58 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 11 Aug 2023 16:10:58 GMT
Subject: RFR: 8314078: HotSpotConstantPool.lookupField() asserts due to
 field changes in ConstantPool.cpp
In-Reply-To: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
References: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
Message-ID: <H7SlOaHPJcWBBxPHSSJZByxObv6tb2FK1U9OVSAMQE8=.a859afa2-719b-4fcc-87eb-ac7f4db74600@github.com>

On Fri, 11 Aug 2023 01:15:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR updates Java code in JVMCI to match the C code changes in [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996) that modified the constant pool layout. Essentially, the indices after a getfield/putfield/getstatic/putstatic bytecode is no longer a CpCacheIndex, but an index for `ConstantPool::resolved_field_entry_at(int field_index)`.
> 
> The assertion (and subsequent crash) happen only in debug builds. Out of pure luck, in product build JVMCI produces the correct output even after [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996), although the code was doing the wrong thing.
> 
> This PR has (so far) two commits:
> 
> - 6527e67b1832087d180d2b50b65aaeca2e244c28 The actual functional change to use the `rawIndex` that follows a field bytecode.
> - c322b8e71d4d9e33bd065e64420101010f9127fc Fixed incorrectly named parameters and variables in the JVMCI code and JavaDoc. In most cases, `cpi` needs to be changed to `rawIndex` to reflect the correct type of the index.
> 
> To help reviewing, I am limiting the renaming to just those affected by the field changes (without the renames, it's hard to validate that I am actually doing the right thing).
> 
> There are still some cases of `cpi` that need to be changed to `rawIndex`. I will fix those in a separate RFE. E.g. in ConstantPool.java:
> 
> 
> default JavaMethod lookupMethod(int cpi, int opcode) {
>     return lookupMethod(cpi, opcode, null);
> }

This looks good.  I don't know how we missed it so thank you for fixing this. Thank you for fixing the variable names, which could have been part of the confusion.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15237#pullrequestreview-1573971843

From iklam at openjdk.org  Fri Aug 11 20:28:58 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 11 Aug 2023 20:28:58 GMT
Subject: RFR: 8314078: HotSpotConstantPool.lookupField() asserts due to
 field changes in ConstantPool.cpp [v2]
In-Reply-To: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
References: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
Message-ID: <lD5-EEXX1v4m0u8MB8qrqYnhGhbYh7Y493k5owjYlwE=.f3fc6933-0250-4db3-87b1-fe8c8e9f9d4c@github.com>

> This PR updates Java code in JVMCI to match the C code changes in [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996) that modified the constant pool layout. Essentially, the indices after a getfield/putfield/getstatic/putstatic bytecode is no longer a CpCacheIndex, but an index for `ConstantPool::resolved_field_entry_at(int field_index)`.
> 
> The assertion (and subsequent crash) happen only in debug builds. Out of pure luck, in product build JVMCI produces the correct output even after [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996), although the code was doing the wrong thing.
> 
> This PR has (so far) two commits:
> 
> - 6527e67b1832087d180d2b50b65aaeca2e244c28 The actual functional change to use the `rawIndex` that follows a field bytecode.
> - c322b8e71d4d9e33bd065e64420101010f9127fc Fixed incorrectly named parameters and variables in the JVMCI code and JavaDoc. In most cases, `cpi` needs to be changed to `rawIndex` to reflect the correct type of the index.
> 
> To help reviewing, I am limiting the renaming to just those affected by the field changes (without the renames, it's hard to validate that I am actually doing the right thing).
> 
> There are still some cases of `cpi` that need to be changed to `rawIndex`. I will fix those in a separate RFE. E.g. in ConstantPool.java:
> 
> 
> default JavaMethod lookupMethod(int cpi, int opcode) {
>     return lookupMethod(cpi, opcode, null);
> }

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @dougxc review: Added comments about rawIndex vs cpi

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15237/files
  - new: https://git.openjdk.org/jdk/pull/15237/files/c322b8e7..21976c06

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

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

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

From iklam at openjdk.org  Fri Aug 11 20:29:30 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 11 Aug 2023 20:29:30 GMT
Subject: RFR: 8314078: HotSpotConstantPool.lookupField() asserts due to
 field changes in ConstantPool.cpp
In-Reply-To: <COsFshpDK4rww7ujq5yfQ4dKpDJtSpcV31fJYrPTbTw=.d2f97b9f-2d60-41ef-be41-b1b291fe3642@github.com>
References: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
 <COsFshpDK4rww7ujq5yfQ4dKpDJtSpcV31fJYrPTbTw=.d2f97b9f-2d60-41ef-be41-b1b291fe3642@github.com>
Message-ID: <pp0SBjaXKrtGGsZXkk9qZNAiRfEvm6bqW7dSd1HdtyQ=.a65ecd88-236f-415c-b938-fd22e37bcd48@github.com>

On Fri, 11 Aug 2023 12:06:36 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Thanks for doing this Ioi.
> 
> In this PR or the follow-up renaming RFE, could you please add a "decoder ring" comment to the javadoc for ConstantPool. An incomplete example:
> 
> ```
>  * The following terminology is used when indexing a constant pool entry:
>  * <ul>
>  * <li>rawIndex - index in the bytecode stream after the opcode (could be rewritten for some bytecodes)</li>
>  * <li>cpi - the class file constant pool index</li>
>  * <li>cpci - a constant pool cache index</li>
>  * </ul>
> ```

Hi Doug, thanks for the review. I added the comments into ConstantPool.java. I omitted cpci as it's not part of the API.

I hope to add more details in the comments when fixing the other incorrectly named variables in [JDK-8314172](https://bugs.openjdk.org/browse/JDK-8314172)

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

PR Comment: https://git.openjdk.org/jdk/pull/15237#issuecomment-1675311831

From kvn at openjdk.org  Sat Aug 12 00:46:28 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 12 Aug 2023 00:46:28 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v5]
In-Reply-To: <gfWDSPQqqRmnEfPA3F3ioavn3bJy9ETrLD_jCrCmNXs=.8597df33-b18c-4a38-9c14-f7a5b4ce41b4@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <gfWDSPQqqRmnEfPA3F3ioavn3bJy9ETrLD_jCrCmNXs=.8597df33-b18c-4a38-9c14-f7a5b4ce41b4@github.com>
Message-ID: <olRcMyBBVLUSi5Tn3Ozl5gZWIKnSweO9zUCC74bTKK4=.7da9cff9-1be7-4802-8696-d5a3b21d0426@github.com>

On Fri, 11 Aug 2023 15:20:59 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
>> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert change in supports_fma.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15133#pullrequestreview-1574578577

From kvn at openjdk.org  Sat Aug 12 00:46:30 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 12 Aug 2023 00:46:30 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v2]
In-Reply-To: <9WeBz8r5aL5xW5HDjw-za0NOTMZU7VEgI0PadSri5aU=.3c958061-4355-4ccf-b3ea-9895bb6dd68a@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <l9_8DmkCojKcBXA_q2mUn_8QX0rfdX2twt0oVmQCiVE=.7cc80c30-3a53-463e-979d-a062d143ad13@github.com>
 <Rtnwno_fbTT9f_pkahS4c0QGMSW7tSbCbNpZ5L0t9JE=.4ebbfdc1-8acd-42f9-9824-7f5898233af8@github.com>
 <9WeBz8r5aL5xW5HDjw-za0NOTMZU7VEgI0PadSri5aU=.3c958061-4355-4ccf-b3ea-9895bb6dd68a@github.com>
Message-ID: <xMtrrhQYs3_92i446e8HX2_-M5ehbcxLeJ7K7yyHdcg=.7230ecb7-14b3-423c-8fd1-629bb37d3490@github.com>

On Thu, 10 Aug 2023 14:28:39 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> I don't having the same logic in two places, because then those two places need to be kept in sync.  Either the stubs should be generated based on is_intrinsic_supported(), or is_intrinsic_supported() should check if the stub was generated.
>
>> I don't having the same logic in two places, because then those two places need to be kept in sync. Either the stubs should be generated based on is_intrinsic_supported(), or is_intrinsic_supported() should check if the stub was generated.
> 
> I have dropped the redundant CPU feature checks, and for those intrinsics with stubs, I tested if the stub pointer is nullptr in `C2Compiler::is_intrinsic_supported`

@mur47x111 please, rerun testing with latest version before integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/15133#issuecomment-1675567914

From jwaters at openjdk.org  Mon Aug 14 04:28:31 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 14 Aug 2023 04:28:31 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v3]
In-Reply-To: <gjeGjGELgfwYRFoy35FhvlknO1dNHgcSbOLQXFq92Hg=.a9138df3-def9-4a68-a7d2-7fba36fa70d1@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com>
 <gjeGjGELgfwYRFoy35FhvlknO1dNHgcSbOLQXFq92Hg=.a9138df3-def9-4a68-a7d2-7fba36fa70d1@github.com>
Message-ID: <2bluDMNS-Ehn5s3wrK3Ah1otV9v98AQOPtG2O_QhjFM=.e4f3eae4-5988-4fea-8e19-779e28be7e67@github.com>

On Tue, 1 Aug 2023 13:17:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Most/all of the PTR_FORMAT => INTPTR_FORMAT changes should not be made. Especially those where the argument is the result of a call to p2i. The p2i thing plus the definition of PTR_FORMAT are a bit of a kludge to work around the variations in the implementations of "%p", which is what one might wish PTR_FORMAT was using.
> 
> I've not looked at the rest yet. It would be easier to do so once the PTR_FORMAT => INTPTR_FORMAT changes were removed.

Understood, will revert them as soon as I can

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

PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1676647733

From yzheng at openjdk.org  Mon Aug 14 06:27:58 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 14 Aug 2023 06:27:58 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v5]
In-Reply-To: <gfWDSPQqqRmnEfPA3F3ioavn3bJy9ETrLD_jCrCmNXs=.8597df33-b18c-4a38-9c14-f7a5b4ce41b4@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <gfWDSPQqqRmnEfPA3F3ioavn3bJy9ETrLD_jCrCmNXs=.8597df33-b18c-4a38-9c14-f7a5b4ce41b4@github.com>
Message-ID: <5Jq7V3PisHoJW_xkn5PCCWpFDVE284iVn_n7qUzymIk=.c1ad14e1-1d37-4c54-92c5-40f8dd479362@github.com>

On Fri, 11 Aug 2023 15:20:59 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
>> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert change in supports_fma.

Passed tier1-3

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

PR Comment: https://git.openjdk.org/jdk/pull/15133#issuecomment-1676730285

From dnsimon at openjdk.org  Mon Aug 14 09:12:00 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 14 Aug 2023 09:12:00 GMT
Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available
 results to JVMCI compilers. [v5]
In-Reply-To: <gfWDSPQqqRmnEfPA3F3ioavn3bJy9ETrLD_jCrCmNXs=.8597df33-b18c-4a38-9c14-f7a5b4ce41b4@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
 <gfWDSPQqqRmnEfPA3F3ioavn3bJy9ETrLD_jCrCmNXs=.8597df33-b18c-4a38-9c14-f7a5b4ce41b4@github.com>
Message-ID: <2IS7HQyrcVXQiRYs5qk7jKfftECxVxfbiGGyT4Spf-Q=.6585bddb-e014-41b7-83ac-fe614cf9cfaf@github.com>

On Fri, 11 Aug 2023 15:20:59 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
>> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert change in supports_fma.

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15133#pullrequestreview-1576399256

From yzheng at openjdk.org  Mon Aug 14 09:12:01 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 14 Aug 2023 09:12:01 GMT
Subject: Integrated: 8313372: [JVMCI] Export
 vmIntrinsics::is_intrinsic_available results to JVMCI compilers.
In-Reply-To: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
References: <pw7Zm4buLo__vq1RBS98NSO8MKzT3so4wTgl6A42w3s=.6d48fbf4-293e-4745-91d5-40bf3964d3d9@github.com>
Message-ID: <O9oUvnQ-o5E4z81Zy-w3d4bAOF8wx4fP8ap7EC9BoG0=.ade1acf1-01f7-40d7-b6db-b84c25da9bd6@github.com>

On Thu, 3 Aug 2023 06:48:27 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`.
> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments.

This pull request has now been integrated.

Changeset: 4164693f
Author:    Yudi Zheng <yzheng at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4164693f3bf15a2f3e03dee72e1ca3fb8d82582c
Stats:     80 lines in 10 files changed: 63 ins; 6 del; 11 mod

8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available results to JVMCI compilers.

Reviewed-by: dnsimon, kvn

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

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

From azafari at openjdk.org  Mon Aug 14 12:11:34 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 14 Aug 2023 12:11:34 GMT
Subject: RFR: 8308850: Change JVM options with small ranges that get
 -Wconversion warnings to 32 bits [v7]
In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
 <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com>
Message-ID: <GdLy-Y19AfE3ilOXnZjBt5l6dpT9RvL9ccoOshlQazU=.243290c9-1873-4783-940d-e76cf81b4ac7@github.com>

On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
>> 
>> ### Tests
>> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
>> tier1 all passed.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a missed option.

Thank you Coleen, Dean, David, Thomas and Ioi for your comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1677184673

From azafari at openjdk.org  Mon Aug 14 12:11:59 2023
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 14 Aug 2023 12:11:59 GMT
Subject: Integrated: 8308850: Change JVM options with small ranges that get
 -Wconversion warnings to 32 bits
In-Reply-To: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
References: <T0jkF1LCBEq28VW3v2QBj7777FpYBiR4KLqeOmbA-Ls=.1f02e261-3235-45fd-80d3-3452772dce1b@github.com>
Message-ID: <YAEc09UAt6XQOYX33UVqoktl9g0CFiplhmrOxmGTcLc=.eeaf2c78-2805-4226-8189-1b1eac4fc4dc@github.com>

On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected.
> 
> ### Tests
> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug
> tier1 all passed.

This pull request has now been integrated.

Changeset: 823f5b93
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/823f5b930c917f36bb32aa0d0bda3ef0187db875
Stats:     22 lines in 7 files changed: 0 ins; 0 del; 22 mod

8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits

Reviewed-by: dholmes, coleenp, dlong

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

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

From iklam at openjdk.org  Mon Aug 14 15:54:29 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Aug 2023 15:54:29 GMT
Subject: RFR: 8314078: HotSpotConstantPool.lookupField() asserts due to
 field changes in ConstantPool.cpp
In-Reply-To: <COsFshpDK4rww7ujq5yfQ4dKpDJtSpcV31fJYrPTbTw=.d2f97b9f-2d60-41ef-be41-b1b291fe3642@github.com>
References: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
 <COsFshpDK4rww7ujq5yfQ4dKpDJtSpcV31fJYrPTbTw=.d2f97b9f-2d60-41ef-be41-b1b291fe3642@github.com>
Message-ID: <qzMh02avwCa00qAiLPtUks3HOxd1ZNxfMQKyRylQDMU=.c8e6ecca-32b2-47d4-b8eb-2e75a2b1e81b@github.com>

On Fri, 11 Aug 2023 12:06:36 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR updates Java code in JVMCI to match the C code changes in [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996) that modified the constant pool layout. Essentially, the indices after a getfield/putfield/getstatic/putstatic bytecode is no longer a CpCacheIndex, but an index for `ConstantPool::resolved_field_entry_at(int field_index)`.
>> 
>> The assertion (and subsequent crash) happen only in debug builds. Out of pure luck, in product build JVMCI produces the correct output even after [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996), although the code was doing the wrong thing.
>> 
>> This PR has (so far) two commits:
>> 
>> - 6527e67b1832087d180d2b50b65aaeca2e244c28 The actual functional change to use the `rawIndex` that follows a field bytecode.
>> - c322b8e71d4d9e33bd065e64420101010f9127fc Fixed incorrectly named parameters and variables in the JVMCI code and JavaDoc. In most cases, `cpi` needs to be changed to `rawIndex` to reflect the correct type of the index.
>> 
>> To help reviewing, I am limiting the renaming to just those affected by the field changes (without the renames, it's hard to validate that I am actually doing the right thing).
>> 
>> There are still some cases of `cpi` that need to be changed to `rawIndex`. I will fix those in a separate RFE. E.g. in ConstantPool.java:
>> 
>> 
>> default JavaMethod lookupMethod(int cpi, int opcode) {
>>     return lookupMethod(cpi, opcode, null);
>> }
>
> Thanks for doing this Ioi.
> 
> In this PR or the follow-up renaming RFE, could you please add a "decoder ring" comment to the javadoc for ConstantPool. An incomplete example:
> 
>  * The following terminology is used when indexing a constant pool entry:
>  * <ul>
>  * <li>rawIndex - index in the bytecode stream after the opcode (could be rewritten for some bytecodes)</li>
>  * <li>cpi - the class file constant pool index</li>
>  * <li>cpci - a constant pool cache index</li>
>  * </ul>

Thanks @dougxc and @coleenp for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15237#issuecomment-1677571227

From iklam at openjdk.org  Mon Aug 14 15:55:29 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Aug 2023 15:55:29 GMT
Subject: Integrated: 8314078: HotSpotConstantPool.lookupField() asserts due to
 field changes in ConstantPool.cpp
In-Reply-To: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
References: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
Message-ID: <JwYTy9BMPtBSHpdAeJP1laCAutuvLf-GiQ7-Wwq3dXA=.0f46439d-372d-4a56-9a11-f2f190f2efed@github.com>

On Fri, 11 Aug 2023 01:15:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR updates Java code in JVMCI to match the C code changes in [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996) that modified the constant pool layout. Essentially, the indices after a getfield/putfield/getstatic/putstatic bytecode is no longer a CpCacheIndex, but an index for `ConstantPool::resolved_field_entry_at(int field_index)`.
> 
> The assertion (and subsequent crash) happen only in debug builds. Out of pure luck, in product build JVMCI produces the correct output even after [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996), although the code was doing the wrong thing.
> 
> This PR has (so far) two commits:
> 
> - 6527e67b1832087d180d2b50b65aaeca2e244c28 The actual functional change to use the `rawIndex` that follows a field bytecode.
> - c322b8e71d4d9e33bd065e64420101010f9127fc Fixed incorrectly named parameters and variables in the JVMCI code and JavaDoc. In most cases, `cpi` needs to be changed to `rawIndex` to reflect the correct type of the index.
> 
> To help reviewing, I am limiting the renaming to just those affected by the field changes (without the renames, it's hard to validate that I am actually doing the right thing).
> 
> There are still some cases of `cpi` that need to be changed to `rawIndex`. I will fix those in a separate RFE. E.g. in ConstantPool.java:
> 
> 
> default JavaMethod lookupMethod(int cpi, int opcode) {
>     return lookupMethod(cpi, opcode, null);
> }

This pull request has now been integrated.

Changeset: 911d1dbb
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/911d1dbbf7362693c736b905b42e5150fc4f8a96
Stats:     131 lines in 5 files changed: 70 ins; 8 del; 53 mod

8314078: HotSpotConstantPool.lookupField() asserts due to field changes in ConstantPool.cpp

Reviewed-by: dnsimon, coleenp

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

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

From jwaters at openjdk.org  Tue Aug 15 03:10:38 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 15 Aug 2023 03:10:38 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v4]
In-Reply-To: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
Message-ID: <syQni99aXG6hWOfE4dX6Le1k4L-U1Z54rU310ltQPXI=.94b6af85-4bc2-4783-9717-b75da81cedb4@github.com>

> Fix several formatting errors on Windows

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

 - Merge branch 'openjdk:master' into format
 - zPhysicalMemoryBacking_windows.cpp
 - Bug
 - 8313302

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15063/files
  - new: https://git.openjdk.org/jdk/pull/15063/files/db9102a2..ddf2f723

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

  Stats: 24613 lines in 1039 files changed: 11414 ins; 6492 del; 6707 mod
  Patch: https://git.openjdk.org/jdk/pull/15063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15063/head:pull/15063

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

From iklam at openjdk.org  Tue Aug 15 03:56:21 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Aug 2023 03:56:21 GMT
Subject: RFR: 8314248: Remove HotSpotConstantPool::isResolvedDynamicInvoke
Message-ID: <Ex3r4flb_XiXE-9-PhtEaQfSQ8txPeDOmx3qZOmsIAY=.99023442-d4f3-42ce-8f83-ec2bc1432d84@github.com>

This method is not used and its implementation is wrong. It should be removed.

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

Commit messages:
 - 8314248: Remove HotSpotConstantPool::isResolvedDynamicInvoke

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

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

From thartmann at openjdk.org  Tue Aug 15 06:15:06 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 15 Aug 2023 06:15:06 GMT
Subject: RFR: 8314248: Remove HotSpotConstantPool::isResolvedDynamicInvoke
In-Reply-To: <Ex3r4flb_XiXE-9-PhtEaQfSQ8txPeDOmx3qZOmsIAY=.99023442-d4f3-42ce-8f83-ec2bc1432d84@github.com>
References: <Ex3r4flb_XiXE-9-PhtEaQfSQ8txPeDOmx3qZOmsIAY=.99023442-d4f3-42ce-8f83-ec2bc1432d84@github.com>
Message-ID: <5eOVMCPWZ9NSz7zOq9OTh-D1MplPaSRDZ1_VS8LhVyQ=.8af3d336-4d3f-43a7-876f-3c92f1de9941@github.com>

On Tue, 15 Aug 2023 03:48:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This method is not used and its implementation is wrong. It should be removed.

Looks good to me but JVMCI experts should also review this (@dougxc).

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15283#pullrequestreview-1578023819

From dnsimon at openjdk.org  Tue Aug 15 06:53:07 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 15 Aug 2023 06:53:07 GMT
Subject: RFR: 8314248: Remove HotSpotConstantPool::isResolvedDynamicInvoke
In-Reply-To: <Ex3r4flb_XiXE-9-PhtEaQfSQ8txPeDOmx3qZOmsIAY=.99023442-d4f3-42ce-8f83-ec2bc1432d84@github.com>
References: <Ex3r4flb_XiXE-9-PhtEaQfSQ8txPeDOmx3qZOmsIAY=.99023442-d4f3-42ce-8f83-ec2bc1432d84@github.com>
Message-ID: <nRuj3bb8gIf3v1jCmwd1uLrkn-7CZIMpUe4IDygdvds=.fc40b53d-067f-4617-9789-7176d33523ba@github.com>

On Tue, 15 Aug 2023 03:48:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This method is not used and its implementation is wrong. It should be removed.

LGTM. I think this is a leftover from jaotc.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15283#pullrequestreview-1578052639

From shade at openjdk.org  Tue Aug 15 08:57:16 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Aug 2023 08:57:16 GMT
Subject: RFR: 8314078: HotSpotConstantPool.lookupField() asserts due to
 field changes in ConstantPool.cpp [v2]
In-Reply-To: <lD5-EEXX1v4m0u8MB8qrqYnhGhbYh7Y493k5owjYlwE=.f3fc6933-0250-4db3-87b1-fe8c8e9f9d4c@github.com>
References: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
 <lD5-EEXX1v4m0u8MB8qrqYnhGhbYh7Y493k5owjYlwE=.f3fc6933-0250-4db3-87b1-fe8c8e9f9d4c@github.com>
Message-ID: <dI2GLcjJNfZNiH0MWekN58qHyPbsXZ5ue0YLfHIiebM=.5968b577-ecac-40ce-95ac-a498c06ce1ef@github.com>

On Fri, 11 Aug 2023 20:28:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR updates Java code in JVMCI to match the C code changes in [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996) that modified the constant pool layout. Essentially, the indices after a getfield/putfield/getstatic/putstatic bytecode is no longer a CpCacheIndex, but an index for `ConstantPool::resolved_field_entry_at(int field_index)`.
>> 
>> The assertion (and subsequent crash) happen only in debug builds. Out of pure luck, in product build JVMCI produces the correct output even after [JDK-8301996](https://bugs.openjdk.java.net/browse/JDK-8301996), although the code was doing the wrong thing.
>> 
>> This PR has (so far) two commits:
>> 
>> - 6527e67b1832087d180d2b50b65aaeca2e244c28 The actual functional change to use the `rawIndex` that follows a field bytecode.
>> - c322b8e71d4d9e33bd065e64420101010f9127fc Fixed incorrectly named parameters and variables in the JVMCI code and JavaDoc. In most cases, `cpi` needs to be changed to `rawIndex` to reflect the correct type of the index.
>> 
>> To help reviewing, I am limiting the renaming to just those affected by the field changes (without the renames, it's hard to validate that I am actually doing the right thing).
>> 
>> There are still some cases of `cpi` that need to be changed to `rawIndex`. I will fix those in a separate RFE. E.g. in ConstantPool.java:
>> 
>> 
>> default JavaMethod lookupMethod(int cpi, int opcode) {
>>     return lookupMethod(cpi, opcode, null);
>> }
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dougxc review: Added comments about rawIndex vs cpi

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 783:

> 781:     @Override
> 782:     public JavaField lookupField(int rawIndex, ResolvedJavaMethod method, int opcode) {
> 783:         final int cpi = compilerToVM().decodeFieldIndexToCPIndex(this, rawIndex);

I have the new warning here: `cpi` is not used. I guess it is correct, seeing how methods are accepting `rawIndex` now, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15237#discussion_r1294346394

From iklam at openjdk.org  Tue Aug 15 15:10:19 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Aug 2023 15:10:19 GMT
Subject: RFR: 8314078: HotSpotConstantPool.lookupField() asserts due to
 field changes in ConstantPool.cpp [v2]
In-Reply-To: <dI2GLcjJNfZNiH0MWekN58qHyPbsXZ5ue0YLfHIiebM=.5968b577-ecac-40ce-95ac-a498c06ce1ef@github.com>
References: <Th-cL_m3E6CXXxu34VVeESUVxOrNoLn0rtXEnZ-8eGs=.b741ee7b-d479-4624-aa40-04232f568209@github.com>
 <lD5-EEXX1v4m0u8MB8qrqYnhGhbYh7Y493k5owjYlwE=.f3fc6933-0250-4db3-87b1-fe8c8e9f9d4c@github.com>
 <dI2GLcjJNfZNiH0MWekN58qHyPbsXZ5ue0YLfHIiebM=.5968b577-ecac-40ce-95ac-a498c06ce1ef@github.com>
Message-ID: <zKr5pSaggU54IxVyzQlrnUpG_Psg_QYfj06gw2e3L2g=.83e03a1d-298b-44bc-a74d-6a7289cd36a9@github.com>

On Tue, 15 Aug 2023 08:54:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dougxc review: Added comments about rawIndex vs cpi
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 783:
> 
>> 781:     @Override
>> 782:     public JavaField lookupField(int rawIndex, ResolvedJavaMethod method, int opcode) {
>> 783:         final int cpi = compilerToVM().decodeFieldIndexToCPIndex(this, rawIndex);
> 
> I have the new warning here: `cpi` is not used. I guess it is correct, seeing how methods are accepting `rawIndex` now, right?

You're right. `cpi` is not used, as the next line uses `rawIndex` to obtain information about the field bytecode.


final int nameAndTypeIndex = getNameAndTypeRefIndexAt(rawIndex, opcode);


I'll remove the `cpi` line in my next JVMCI cleanup PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15237#discussion_r1294723660

From iklam at openjdk.org  Tue Aug 15 15:57:16 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Aug 2023 15:57:16 GMT
Subject: RFR: 8314248: Remove HotSpotConstantPool::isResolvedDynamicInvoke
In-Reply-To: <5eOVMCPWZ9NSz7zOq9OTh-D1MplPaSRDZ1_VS8LhVyQ=.8af3d336-4d3f-43a7-876f-3c92f1de9941@github.com>
References: <Ex3r4flb_XiXE-9-PhtEaQfSQ8txPeDOmx3qZOmsIAY=.99023442-d4f3-42ce-8f83-ec2bc1432d84@github.com>
 <5eOVMCPWZ9NSz7zOq9OTh-D1MplPaSRDZ1_VS8LhVyQ=.8af3d336-4d3f-43a7-876f-3c92f1de9941@github.com>
Message-ID: <aW_4Sj6GOmrxF0nX_uruj9aQ65SVQTNHuDFmKLtFPq8=.3bc1521b-d140-4229-a5e0-ed12cdd02219@github.com>

On Tue, 15 Aug 2023 06:12:35 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> This method is not used and its implementation is wrong. It should be removed.
>
> Looks good to me but JVMCI experts should also review this (@dougxc).

Thanks @TobiHartmann and @dougxc for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15283#issuecomment-1679180043

From iklam at openjdk.org  Tue Aug 15 15:57:18 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Aug 2023 15:57:18 GMT
Subject: Integrated: 8314248: Remove
 HotSpotConstantPool::isResolvedDynamicInvoke
In-Reply-To: <Ex3r4flb_XiXE-9-PhtEaQfSQ8txPeDOmx3qZOmsIAY=.99023442-d4f3-42ce-8f83-ec2bc1432d84@github.com>
References: <Ex3r4flb_XiXE-9-PhtEaQfSQ8txPeDOmx3qZOmsIAY=.99023442-d4f3-42ce-8f83-ec2bc1432d84@github.com>
Message-ID: <kix6nvi-Ig8fdq6wzDny8hzk3Um31LiUY3P4Y7vrrYY=.e3efd2e5-4859-4444-bbd7-dd3d31dd8d3d@github.com>

On Tue, 15 Aug 2023 03:48:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This method is not used and its implementation is wrong. It should be removed.

This pull request has now been integrated.

Changeset: 80809ef4
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80809ef4ccdfd2ebfa9fd1eaf393d14e443dc760
Stats:     20 lines in 1 file changed: 0 ins; 20 del; 0 mod

8314248: Remove HotSpotConstantPool::isResolvedDynamicInvoke

Reviewed-by: thartmann, dnsimon

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

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

From coleenp at openjdk.org  Tue Aug 15 18:01:37 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Aug 2023 18:01:37 GMT
Subject: RFR: 8314247: JVMCI: expected int64_t but
 JavaThread::_held_monitor_count is of type intx
Message-ID: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>

Fix graal error with @iklam's fix of making intx and int64_t synonyms.  Tested with new test in jvmci tests.

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

Commit messages:
 - 8314247: JVMCI: expected int64_t but JavaThread::_held_monitor_count is of type intx

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

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

From iklam at openjdk.org  Tue Aug 15 18:17:09 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Aug 2023 18:17:09 GMT
Subject: RFR: 8314247: JVMCI: expected int64_t but
 JavaThread::_held_monitor_count is of type intx
In-Reply-To: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>
References: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>
Message-ID: <EoG2bGPhjd82lLuWgJdDIOmDFzLTgHPxRxRVYWyFDDY=.3f226b22-fc54-4a20-9a14-7f690709c974@github.com>

On Tue, 15 Aug 2023 17:54:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Fix graal error with @iklam's fix of making intx and int64_t synonyms.  Tested with new test in jvmci tests.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15295#pullrequestreview-1579134378

From coleenp at openjdk.org  Tue Aug 15 18:35:05 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Aug 2023 18:35:05 GMT
Subject: RFR: 8314247: JVMCI: expected int64_t but
 JavaThread::_held_monitor_count is of type intx
In-Reply-To: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>
References: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>
Message-ID: <rF9ydT1ol4DjXZYbOFCLioUr1-wmx0RB5HYbuWRkN-E=.e8b6c887-fd1d-4d1f-b1c4-616d384463e4@github.com>

On Tue, 15 Aug 2023 17:54:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Fix graal error with @iklam's fix of making intx and int64_t synonyms.  Tested with new test in jvmci tests.

@dougxc Is this okay with you?  Otherwise, I'm not really sure how you want to fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/15295#issuecomment-1679409937

From dnsimon at openjdk.org  Tue Aug 15 20:42:08 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 15 Aug 2023 20:42:08 GMT
Subject: RFR: 8314247: JVMCI: expected int64_t but
 JavaThread::_held_monitor_count is of type intx
In-Reply-To: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>
References: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>
Message-ID: <aKKNn1VCGQiaXT-SEKbt52E8V1VTvXVA6iP2RTc_ZQE=.f328945c-048e-4692-b46e-ec4adf5ab7e9@github.com>

On Tue, 15 Aug 2023 17:54:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Fix graal error with @iklam's fix of making intx and int64_t synonyms.  Tested with new test in jvmci tests.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java line 325:

> 323: 
> 324:         // Make sure the native type is still the type we expect.
> 325:         if (cppType != null && !typeEquals(cppType, entry.type)) {

We have conditional code in Graal (e.g. [here](https://github.com/oracle/graal/blob/5097b1dabf01fd6d2ea1ea3b470060a138d49fa2/compiler/src/jdk.internal.vm.compiler/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java#L392-L405)) to deal with type changes in vmstructs so there's no need to fix it here. I'd prefer to not have this code do type aliasing like this as it might hide other changes we need to make in Graal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15295#discussion_r1295089272

From coleenp at openjdk.org  Tue Aug 15 21:21:18 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Aug 2023 21:21:18 GMT
Subject: RFR: 8314247: JVMCI: expected int64_t but
 JavaThread::_held_monitor_count is of type intx
In-Reply-To: <aKKNn1VCGQiaXT-SEKbt52E8V1VTvXVA6iP2RTc_ZQE=.f328945c-048e-4692-b46e-ec4adf5ab7e9@github.com>
References: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>
 <aKKNn1VCGQiaXT-SEKbt52E8V1VTvXVA6iP2RTc_ZQE=.f328945c-048e-4692-b46e-ec4adf5ab7e9@github.com>
Message-ID: <B694YsZ1Vdk-beTMeaaqQZB4lXTm3PuIfsJW68xQXLw=.87b06066-ff30-415b-a415-3b6315e3cd4a@github.com>

On Tue, 15 Aug 2023 20:39:47 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Fix graal error with @iklam's fix of making intx and int64_t synonyms.  Tested with new test in jvmci tests.
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java line 325:
> 
>> 323: 
>> 324:         // Make sure the native type is still the type we expect.
>> 325:         if (cppType != null && !typeEquals(cppType, entry.type)) {
> 
> We have conditional code in Graal (e.g. [here](https://github.com/oracle/graal/blob/5097b1dabf01fd6d2ea1ea3b470060a138d49fa2/compiler/src/jdk.internal.vm.compiler/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java#L392-L405)) to deal with type changes in vmstructs so there's no need to fix it here. I'd prefer to not have this code do type aliasing like this as it might hide other changes we need to make in Graal.

Okay, if you can fix it in Graal, that would be great.  Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15295#discussion_r1295125128

From coleenp at openjdk.org  Tue Aug 15 21:21:19 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Aug 2023 21:21:19 GMT
Subject: Withdrawn: 8314247: JVMCI: expected int64_t but
 JavaThread::_held_monitor_count is of type intx
In-Reply-To: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>
References: <hUDv-Cbr1_NtJbVarLciXf9FGMSQnVBwNtVCMOdaGF8=.46f194a8-6c29-44f6-b3fb-e4f3b85b5174@github.com>
Message-ID: <2GdofM4avQxfvB0JdSGe13rGjE9WyUVkW6YtqZ8eHG8=.47cd2b8c-c1d5-4922-a781-0d188bec5c55@github.com>

On Tue, 15 Aug 2023 17:54:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Fix graal error with @iklam's fix of making intx and int64_t synonyms.  Tested with new test in jvmci tests.

This pull request has been closed without being integrated.

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

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

From iklam at openjdk.org  Tue Aug 15 22:24:29 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Aug 2023 22:24:29 GMT
Subject: RFR: 8314249: Refactor handling of invokedynamic in JVMCI ConstantPool
Message-ID: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>

This PR is part of the clean up JVMCI to track [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993), where the  constant pool cache is being removed (as of now, only method references use the CpCache).

1. `rawIndexToConstantPoolIndex()` is used only for the `invokedynamic` bytecode. It should be renamed to `indyIndexConstantPoolIndex()`

2. `rawIndexToConstantPoolCacheIndex()` should not be called for the `invokedynamic` bytecode, which doesn't use cpCache entries after [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995).

3. Some `cpi` parameters should be renamed to `rawIndex` or `which`

4. Added a test case for `ConstantPool.lookupAppendix()`, which was not tested in the JDK repo.

I added comments about the 4 types of indices used in HotSpotConstantPool.java: `cpi`, `rawIndex`, `cpci` and `which`. The latter two types will be removed after [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993) is complete.

Note that there are still some incorrect use of `cpi` in the implementation and test cases. Those will be cleaned up in [JDK-8314172](https://bugs.openjdk.org/browse/JDK-8314172)

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

Commit messages:
 - fixed whitespace
 - fixed test
 - added test case for ConstantPool.lookupAppendix; other code touch by this PR already have test cases
 - fixed comments
 - Added docs about the names we use for indices: cpi, rawIndex, cpci and which
 - 8314249: Refactor handling of invokedynamic in JVMCI ConstantPool

Changes: https://git.openjdk.org/jdk/pull/15297/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15297&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314249
  Stats: 188 lines in 6 files changed: 120 ins; 23 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/15297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15297/head:pull/15297

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

From jwaters at openjdk.org  Wed Aug 16 02:21:51 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 16 Aug 2023 02:21:51 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v5]
In-Reply-To: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
Message-ID: <jVAr1OBSSXCHDzJpic7v5Q4iDa9osliEIio9sfZMP8E=.71e1c777-67b9-46eb-8ef1-7b59860ef570@github.com>

> Fix several formatting errors on Windows

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Remove whitespace
 - Revert changes of INTPTR_FORMAT, minor improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15063/files
  - new: https://git.openjdk.org/jdk/pull/15063/files/ddf2f723..9402a57c

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

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

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

From dnsimon at openjdk.org  Wed Aug 16 07:17:07 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Aug 2023 07:17:07 GMT
Subject: RFR: 8314249: Refactor handling of invokedynamic in JVMCI
 ConstantPool
In-Reply-To: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
References: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
Message-ID: <eV9z2AF-Ojku9XmDos_C_-y-upgPj1RHuzT-hHKjhZQ=.ace2d799-cc2c-4355-9590-7e1d055fb1da@github.com>

On Tue, 15 Aug 2023 20:03:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR is part of the clean up JVMCI to track [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993), where the  constant pool cache is being removed (as of now, only method references use the CpCache).
> 
> 1. `rawIndexToConstantPoolIndex()` is used only for the `invokedynamic` bytecode. It should be renamed to `indyIndexConstantPoolIndex()`
> 
> 2. `rawIndexToConstantPoolCacheIndex()` should not be called for the `invokedynamic` bytecode, which doesn't use cpCache entries after [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995).
> 
> 3. Some `cpi` parameters should be renamed to `rawIndex` or `which`
> 
> 4. Added a test case for `ConstantPool.lookupAppendix()`, which was not tested in the JDK repo.
> 
> I added comments about the 4 types of indices used in HotSpotConstantPool.java: `cpi`, `rawIndex`, `cpci` and `which`. The latter two types will be removed after [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993) is complete.
> 
> Note that there are still some incorrect use of `cpi` in the implementation and test cases. Those will be cleaned up in [JDK-8314172](https://bugs.openjdk.org/browse/JDK-8314172)

Marked as reviewed by dnsimon (Reviewer).

Thanks a lot for this cleanup and adding the extra tests.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/CompilerToVM.java line 565:

> 563:      * Gets the appendix object (if any) associated with the entry identified by {@code which}.
> 564:      *
> 565:      * @param which if negative, is treated as an encoded indy index for INVONEDYNAMIC;

INVONEDYNAMIC -> INVOKEDYNAMIC

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 60:

> 58:  * </ul>
> 59:  *
> 60:  * Note that {@code cpci} and {@code which} are used only in the HotSpot-specific implementation. They are not used by the public iterface in jdk.vm.ci.meta.*.

iterface -> iterface

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ConstantPool.java line 179:

> 177:      *
> 178:      * @param index if {@code opcode} is -1,  {@code index} is a constant pool index. Otherwise {@code opcode}
> 179:      *              must be ${code Bytecodes.INVOKEDYNAMIC}, and {@code index} must be the operand of that

`${code Bytecodes.INVOKEDYNAMIC}` -> `{@code INVOKEDYNAMIC}` (in numerous places)

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

PR Review: https://git.openjdk.org/jdk/pull/15297#pullrequestreview-1579923317
PR Comment: https://git.openjdk.org/jdk/pull/15297#issuecomment-1680085580
PR Review Comment: https://git.openjdk.org/jdk/pull/15297#discussion_r1295459900
PR Review Comment: https://git.openjdk.org/jdk/pull/15297#discussion_r1295461310
PR Review Comment: https://git.openjdk.org/jdk/pull/15297#discussion_r1295466901

From stefank at openjdk.org  Wed Aug 16 08:03:16 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 16 Aug 2023 08:03:16 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v5]
In-Reply-To: <jVAr1OBSSXCHDzJpic7v5Q4iDa9osliEIio9sfZMP8E=.71e1c777-67b9-46eb-8ef1-7b59860ef570@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <jVAr1OBSSXCHDzJpic7v5Q4iDa9osliEIio9sfZMP8E=.71e1c777-67b9-46eb-8ef1-7b59860ef570@github.com>
Message-ID: <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com>

On Wed, 16 Aug 2023 02:21:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Fix several formatting errors on Windows
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove whitespace
>  - Revert changes of INTPTR_FORMAT, minor improvements

Changes requested by stefank (Reviewer).

src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 267:

> 265: 
> 266:   if (!res) {
> 267:     fatal_error("Failed to split placeholder", static_cast<uintptr_t>(addr), size);

Suggestion:

    fatal_error("Failed to split placeholder", untype(addr), size);

src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp line 202:

> 200:     if (!res) {
> 201:       fatal("Failed to unmap view " PTR_FORMAT " " SIZE_FORMAT "M (%ld)",
> 202:             static_cast<uintptr_t>(addr), size / M, GetLastError());

Suggestion:

            untype(addr), size / M, GetLastError());

src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp line 242:

> 240: void ZPhysicalMemoryBacking::map(zaddress_unsafe addr, size_t size, zoffset offset) const {
> 241:   assert(is_aligned(untype(offset), ZGranuleSize), "Misaligned: " PTR_FORMAT, untype(offset));
> 242:   assert(is_aligned(untype(addr), ZGranuleSize), "Misaligned: " PTR_FORMAT, static_cast<uintptr_t>(addr));

Suggestion:

  assert(is_aligned(untype(addr), ZGranuleSize), "Misaligned: " PTR_FORMAT, untype(addr));

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

PR Review: https://git.openjdk.org/jdk/pull/15063#pullrequestreview-1580009829
PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1295515784
PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1295516066
PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1295516411

From iklam at openjdk.org  Wed Aug 16 19:34:32 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Aug 2023 19:34:32 GMT
Subject: RFR: 8314249: Refactor handling of invokedynamic in JVMCI
 ConstantPool [v2]
In-Reply-To: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
References: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
Message-ID: <-3xlD1aO8Z6hv9_2bHIr8rneyyAhib-UL4Y_r0R9_LM=.47e09803-88f5-4173-b72b-86e32e779d2f@github.com>

> This PR is part of the clean up JVMCI to track [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993), where the  constant pool cache is being removed (as of now, only method references use the CpCache).
> 
> 1. `rawIndexToConstantPoolIndex()` is used only for the `invokedynamic` bytecode. It should be renamed to `indyIndexConstantPoolIndex()`
> 
> 2. `rawIndexToConstantPoolCacheIndex()` should not be called for the `invokedynamic` bytecode, which doesn't use cpCache entries after [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995).
> 
> 3. Some `cpi` parameters should be renamed to `rawIndex` or `which`
> 
> 4. Added a test case for `ConstantPool.lookupAppendix()`, which was not tested in the JDK repo.
> 
> I added comments about the 4 types of indices used in HotSpotConstantPool.java: `cpi`, `rawIndex`, `cpci` and `which`. The latter two types will be removed after [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993) is complete.
> 
> Note that there are still some incorrect use of `cpi` in the implementation and test cases. Those will be cleaned up in [JDK-8314172](https://bugs.openjdk.org/browse/JDK-8314172)

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @dougxc comments - fixed typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15297/files
  - new: https://git.openjdk.org/jdk/pull/15297/files/337895c6..e09f65fc

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

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

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

From coleenp at openjdk.org  Wed Aug 16 19:53:08 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Aug 2023 19:53:08 GMT
Subject: RFR: 8314249: Refactor handling of invokedynamic in JVMCI
 ConstantPool [v2]
In-Reply-To: <-3xlD1aO8Z6hv9_2bHIr8rneyyAhib-UL4Y_r0R9_LM=.47e09803-88f5-4173-b72b-86e32e779d2f@github.com>
References: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
 <-3xlD1aO8Z6hv9_2bHIr8rneyyAhib-UL4Y_r0R9_LM=.47e09803-88f5-4173-b72b-86e32e779d2f@github.com>
Message-ID: <yo1fYfCfXpULkKw-LCuRRmTmyRLffO1_gd1pu3SDdX0=.4acfa002-9b6c-4923-9ceb-20fd598c8a23@github.com>

On Wed, 16 Aug 2023 19:34:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR is part of the clean up JVMCI to track [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993), where the  constant pool cache is being removed (as of now, only method references use the CpCache).
>> 
>> 1. `rawIndexToConstantPoolIndex()` is used only for the `invokedynamic` bytecode. It should be renamed to `indyIndexConstantPoolIndex()`
>> 
>> 2. `rawIndexToConstantPoolCacheIndex()` should not be called for the `invokedynamic` bytecode, which doesn't use cpCache entries after [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995).
>> 
>> 3. Some `cpi` parameters should be renamed to `rawIndex` or `which`
>> 
>> 4. Added a test case for `ConstantPool.lookupAppendix()`, which was not tested in the JDK repo.
>> 
>> I added comments about the 4 types of indices used in HotSpotConstantPool.java: `cpi`, `rawIndex`, `cpci` and `which`. The latter two types will be removed after [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993) is complete.
>> 
>> Note that there are still some incorrect use of `cpi` in the implementation and test cases. Those will be cleaned up in [JDK-8314172](https://bugs.openjdk.org/browse/JDK-8314172)
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dougxc comments - fixed typos

This makes sense.  Do we run this test with hotspot testing?

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 588:

> 586:     @Override
> 587:     public BootstrapMethodInvocation lookupBootstrapMethodInvocation(int index, int opcode) {
> 588:         int cpi = opcode == -1 ? index : indyIndexConstantPoolIndex(index, opcode);

Why would opcode be -1 here?

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15297#pullrequestreview-1581310736
PR Review Comment: https://git.openjdk.org/jdk/pull/15297#discussion_r1296357340

From dnsimon at openjdk.org  Wed Aug 16 20:31:12 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Aug 2023 20:31:12 GMT
Subject: RFR: 8314249: Refactor handling of invokedynamic in JVMCI
 ConstantPool [v2]
In-Reply-To: <yo1fYfCfXpULkKw-LCuRRmTmyRLffO1_gd1pu3SDdX0=.4acfa002-9b6c-4923-9ceb-20fd598c8a23@github.com>
References: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
 <-3xlD1aO8Z6hv9_2bHIr8rneyyAhib-UL4Y_r0R9_LM=.47e09803-88f5-4173-b72b-86e32e779d2f@github.com>
 <yo1fYfCfXpULkKw-LCuRRmTmyRLffO1_gd1pu3SDdX0=.4acfa002-9b6c-4923-9ceb-20fd598c8a23@github.com>
Message-ID: <5Tp-G3g7Ib9pLcj3PV1TLwy0H_k6Dyz_Th1OqYyu6yw=.0e516d2d-6b55-447e-afce-e78ef919134a@github.com>

On Wed, 16 Aug 2023 19:47:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dougxc comments - fixed typos
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 588:
> 
>> 586:     @Override
>> 587:     public BootstrapMethodInvocation lookupBootstrapMethodInvocation(int index, int opcode) {
>> 588:         int cpi = opcode == -1 ? index : indyIndexConstantPoolIndex(index, opcode);
> 
> Why would opcode be -1 here?

So that tests such as TestDynamicConstant.java can [iterate through the constant pool, looking for invokedynamic related entries](https://github.com/openjdk/jdk/blob/f143380d013b8c0e5ab7ca0026c34e27e7946f69/test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/TestDynamicConstant.java#L356-L359).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15297#discussion_r1296392827

From iklam at openjdk.org  Wed Aug 16 22:03:27 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Aug 2023 22:03:27 GMT
Subject: RFR: 8314249: Refactor handling of invokedynamic in JVMCI
 ConstantPool [v2]
In-Reply-To: <yo1fYfCfXpULkKw-LCuRRmTmyRLffO1_gd1pu3SDdX0=.4acfa002-9b6c-4923-9ceb-20fd598c8a23@github.com>
References: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
 <-3xlD1aO8Z6hv9_2bHIr8rneyyAhib-UL4Y_r0R9_LM=.47e09803-88f5-4173-b72b-86e32e779d2f@github.com>
 <yo1fYfCfXpULkKw-LCuRRmTmyRLffO1_gd1pu3SDdX0=.4acfa002-9b6c-4923-9ceb-20fd598c8a23@github.com>
Message-ID: <vZwhSpHslv4HiVwtKd76Ciog6ftyoZHOWWDxtEppx7s=.81ce11d3-790b-431d-8af5-8199a2f30325@github.com>

On Wed, 16 Aug 2023 19:50:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This makes sense. Do we run this test with hotspot testing?

Yes, tests under `test/hotspot/jtreg/compiler/jvmci` are regularly tested.

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

PR Comment: https://git.openjdk.org/jdk/pull/15297#issuecomment-1681325411

From jwaters at openjdk.org  Thu Aug 17 05:55:30 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Aug 2023 05:55:30 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v5]
In-Reply-To: <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <jVAr1OBSSXCHDzJpic7v5Q4iDa9osliEIio9sfZMP8E=.71e1c777-67b9-46eb-8ef1-7b59860ef570@github.com>
 <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com>
Message-ID: <Bw2G9AXUXczsqagEL725hofPP7W_ThHvwd4pvXPTx9U=.aee8ed58-a223-4689-900b-e2405b71a117@github.com>

On Wed, 16 Aug 2023 07:54:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove whitespace
>>  - Revert changes of INTPTR_FORMAT, minor improvements
>
> src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 267:
> 
>> 265: 
>> 266:   if (!res) {
>> 267:     fatal_error("Failed to split placeholder", static_cast<uintptr_t>(addr), size);
> 
> Suggestion:
> 
>     fatal_error("Failed to split placeholder", untype(addr), size);

won't these trigger assertions inside fatal error reporting code as Thomas mentioned earlier?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1296707683

From jwaters at openjdk.org  Thu Aug 17 06:32:53 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Aug 2023 06:32:53 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v6]
In-Reply-To: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
Message-ID: <aR6dUaRQknR8m3Z8aXKoXRK6A97aZ0ERfDmzsHVpXdg=.084c0522-e4db-45a5-adc5-86ff30cd0ddb@github.com>

> Fix several formatting errors on Windows

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15063/files
  - new: https://git.openjdk.org/jdk/pull/15063/files/9402a57c..b8829f1e

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

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

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

From stefank at openjdk.org  Thu Aug 17 07:45:34 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 17 Aug 2023 07:45:34 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v6]
In-Reply-To: <aR6dUaRQknR8m3Z8aXKoXRK6A97aZ0ERfDmzsHVpXdg=.084c0522-e4db-45a5-adc5-86ff30cd0ddb@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <aR6dUaRQknR8m3Z8aXKoXRK6A97aZ0ERfDmzsHVpXdg=.084c0522-e4db-45a5-adc5-86ff30cd0ddb@github.com>
Message-ID: <YsnvZxGx5QXP_8_jMDAyh2-hkPpZSxiElJSGeqcB8RQ=.eb41e851-ac90-47d5-890a-4cc4551797fc@github.com>

On Thu, 17 Aug 2023 06:32:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Fix several formatting errors on Windows
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Changes requested by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15063#pullrequestreview-1581976221

From stefank at openjdk.org  Thu Aug 17 07:45:39 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 17 Aug 2023 07:45:39 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v5]
In-Reply-To: <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <jVAr1OBSSXCHDzJpic7v5Q4iDa9osliEIio9sfZMP8E=.71e1c777-67b9-46eb-8ef1-7b59860ef570@github.com>
 <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com>
Message-ID: <GcfDvSkghVYLk_aGTrh72I9JhdcKuRDiceF_uZbqRxE=.97280819-bf93-4ec9-ab5b-3439cc50995a@github.com>

On Wed, 16 Aug 2023 07:54:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove whitespace
>>  - Revert changes of INTPTR_FORMAT, minor improvements
>
> src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp line 202:
> 
>> 200:     if (!res) {
>> 201:       fatal("Failed to unmap view " PTR_FORMAT " " SIZE_FORMAT "M (%ld)",
>> 202:             static_cast<uintptr_t>(addr), size / M, GetLastError());
> 
> Suggestion:
> 
>             untype(addr), size / M, GetLastError());

This suggestion is still valid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1296809821

From stefank at openjdk.org  Thu Aug 17 07:45:37 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 17 Aug 2023 07:45:37 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v5]
In-Reply-To: <Bw2G9AXUXczsqagEL725hofPP7W_ThHvwd4pvXPTx9U=.aee8ed58-a223-4689-900b-e2405b71a117@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <jVAr1OBSSXCHDzJpic7v5Q4iDa9osliEIio9sfZMP8E=.71e1c777-67b9-46eb-8ef1-7b59860ef570@github.com>
 <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com>
 <Bw2G9AXUXczsqagEL725hofPP7W_ThHvwd4pvXPTx9U=.aee8ed58-a223-4689-900b-e2405b71a117@github.com>
Message-ID: <3Ww5RQVFcmJwR7ntIxoMhrbTMO6LhqzTKD7GZe1QOX0=.390291e8-5e00-4308-b290-1d7783bca587@github.com>

On Thu, 17 Aug 2023 05:53:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 267:
>> 
>>> 265: 
>>> 266:   if (!res) {
>>> 267:     fatal_error("Failed to split placeholder", static_cast<uintptr_t>(addr), size);
>> 
>> Suggestion:
>> 
>>     fatal_error("Failed to split placeholder", untype(addr), size);
>
> won't these trigger assertions inside fatal error reporting code as Thomas mentioned earlier?

No. See:

inline uintptr_t untype(zaddress_unsafe addr) {
  return static_cast<uintptr_t>(addr);
}


I wonder if Thomas were thinking about the opposite operation, which converts an uintptr_t to a zaddress_unsafe:

inline zaddress_unsafe to_zaddress_unsafe(uintptr_t value) {
  const zaddress_unsafe addr = zaddress_unsafe(value);
  assert_is_valid(addr);
  return addr;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1296800443

From jwaters at openjdk.org  Thu Aug 17 08:32:01 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Aug 2023 08:32:01 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v7]
In-Reply-To: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
Message-ID: <2DcPIgu4u8-toGNKtbJRolqEJbKrNQ5j2v2_k_ipl3g=.11b771c9-e8bc-43df-ab34-2f7f4fbe28d2@github.com>

> Fix several formatting errors on Windows

Julian Waters has updated the pull request with a new target base due to a merge or a rebase.

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

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

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

From jwaters at openjdk.org  Thu Aug 17 08:32:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 17 Aug 2023 08:32:02 GMT
Subject: RFR: 8313302: Fix formatting errors on Windows [v6]
In-Reply-To: <aR6dUaRQknR8m3Z8aXKoXRK6A97aZ0ERfDmzsHVpXdg=.084c0522-e4db-45a5-adc5-86ff30cd0ddb@github.com>
References: <yRux2En49aeeuM4Nx80zhcC5wFa0id7ziEjbHp0VmMk=.952d2fe3-448c-44a6-b49d-fc28496e0fe4@github.com>
 <aR6dUaRQknR8m3Z8aXKoXRK6A97aZ0ERfDmzsHVpXdg=.084c0522-e4db-45a5-adc5-86ff30cd0ddb@github.com>
Message-ID: <u6Uj1IF5VLHKtvJr8czZU-Gy7YwWoGePlugBVakWuU4=.b8ba1bd6-d00b-4d37-98a1-72a5f3f3aa5f@github.com>

On Thu, 17 Aug 2023 06:32:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Fix several formatting errors on Windows
>
> Julian Waters has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.

Closed due to merge conflicts

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

PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1681856161

From iklam at openjdk.org  Thu Aug 17 22:54:35 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Aug 2023 22:54:35 GMT
Subject: RFR: 8314249: Refactor handling of invokedynamic in JVMCI
 ConstantPool
In-Reply-To: <eV9z2AF-Ojku9XmDos_C_-y-upgPj1RHuzT-hHKjhZQ=.ace2d799-cc2c-4355-9590-7e1d055fb1da@github.com>
References: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
 <eV9z2AF-Ojku9XmDos_C_-y-upgPj1RHuzT-hHKjhZQ=.ace2d799-cc2c-4355-9590-7e1d055fb1da@github.com>
Message-ID: <x_z4-IRMY-Cx7XA-faXFXITIKUoM07dqtxUIBK4xdNA=.dc896a42-435a-4652-8694-5d105cdc93b3@github.com>

On Wed, 16 Aug 2023 07:14:33 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR is part of the clean up JVMCI to track [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993), where the  constant pool cache is being removed (as of now, only method references use the CpCache).
>> 
>> 1. `rawIndexToConstantPoolIndex()` is used only for the `invokedynamic` bytecode. It should be renamed to `indyIndexConstantPoolIndex()`
>> 
>> 2. `rawIndexToConstantPoolCacheIndex()` should not be called for the `invokedynamic` bytecode, which doesn't use cpCache entries after [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995).
>> 
>> 3. Some `cpi` parameters should be renamed to `rawIndex` or `which`
>> 
>> 4. Added a test case for `ConstantPool.lookupAppendix()`, which was not tested in the JDK repo.
>> 
>> I added comments about the 4 types of indices used in HotSpotConstantPool.java: `cpi`, `rawIndex`, `cpci` and `which`. The latter two types will be removed after [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993) is complete.
>> 
>> Note that there are still some incorrect use of `cpi` in the implementation and test cases. Those will be cleaned up in [JDK-8314172](https://bugs.openjdk.org/browse/JDK-8314172)
>
> Thanks a lot for this cleanup and adding the extra tests.

Thanks @dougxc @coleenp for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15297#issuecomment-1683078290

From iklam at openjdk.org  Thu Aug 17 22:54:36 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Aug 2023 22:54:36 GMT
Subject: Integrated: 8314249: Refactor handling of invokedynamic in JVMCI
 ConstantPool
In-Reply-To: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
References: <6pkU1viiXcWvXP5KwsD9-8HYEy_SoPkR6-Ea4l9OWhs=.dba83e93-e1e8-4778-b2af-f5a1b7792a73@github.com>
Message-ID: <q4DvUP3RbYYVrInb1piRC2AtJfa9ThHB1z36kRFG8EU=.79e3767a-913c-40f7-9976-3188b6037308@github.com>

On Tue, 15 Aug 2023 20:03:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR is part of the clean up JVMCI to track [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993), where the  constant pool cache is being removed (as of now, only method references use the CpCache).
> 
> 1. `rawIndexToConstantPoolIndex()` is used only for the `invokedynamic` bytecode. It should be renamed to `indyIndexConstantPoolIndex()`
> 
> 2. `rawIndexToConstantPoolCacheIndex()` should not be called for the `invokedynamic` bytecode, which doesn't use cpCache entries after [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995).
> 
> 3. Some `cpi` parameters should be renamed to `rawIndex` or `which`
> 
> 4. Added a test case for `ConstantPool.lookupAppendix()`, which was not tested in the JDK repo.
> 
> I added comments about the 4 types of indices used in HotSpotConstantPool.java: `cpi`, `rawIndex`, `cpci` and `which`. The latter two types will be removed after [JDK-8301993](https://bugs.openjdk.org/browse/JDK-8301993) is complete.
> 
> Note that there are still some incorrect use of `cpi` in the implementation and test cases. Those will be cleaned up in [JDK-8314172](https://bugs.openjdk.org/browse/JDK-8314172)

This pull request has now been integrated.

Changeset: 0299364d
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0299364d85a66c35e616148cbbde314b7d4fb05a
Stats:     189 lines in 6 files changed: 121 ins; 23 del; 45 mod

8314249: Refactor handling of invokedynamic in JVMCI ConstantPool

Reviewed-by: dnsimon, coleenp

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

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

From ayang at openjdk.org  Mon Aug 21 12:32:35 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 21 Aug 2023 12:32:35 GMT
Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of
 HeapRegion
Message-ID: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>

Use unsigned type for heap-region-size related shifts in HeapRegion.
 
Test: tier1-3

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

Commit messages:
 - g1-heap-region-log-uint

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

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

From duke at openjdk.org  Tue Aug 22 03:38:47 2023
From: duke at openjdk.org (xpbob)
Date: Tue, 22 Aug 2023 03:38:47 GMT
Subject: RFR: 8314688: VM build without C1 fails after JDK-8313372
Message-ID: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>

[8314688: VM build without C1 fails after JDK-8313372]

./configure --with-jvm-features=-compiler1 --with-debug-level=release
make images JOBS=32


jvmciCompilerToVMInit.o:make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:252: more undefined references to `Compiler::is_intrinsic_supported(vmIntrinsicID)' follow

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

Commit messages:
 - 8314688: VM build without C1 fails after JDK-8313372

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

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

From duke at openjdk.org  Tue Aug 22 03:47:51 2023
From: duke at openjdk.org (xpbob)
Date: Tue, 22 Aug 2023 03:47:51 GMT
Subject: RFR: 8314688: VM build without C1 fails after JDK-8313372 [v2]
In-Reply-To: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
References: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
Message-ID: <S_n9xC2t1YW8WGPTxByhq0d4bqyM75VuWBrQrN6II0c=.6357e868-bdab-40e3-8fa6-ab48950e4b94@github.com>

> [8314688: VM build without C1 fails after JDK-8313372]
> 
> ./configure --with-jvm-features=-compiler1 --with-debug-level=release
> make images JOBS=32
> 
> 
> jvmciCompilerToVMInit.o:make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:252: more undefined references to `Compiler::is_intrinsic_supported(vmIntrinsicID)' follow

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

  code format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15376/files
  - new: https://git.openjdk.org/jdk/pull/15376/files/97efc583..6937badb

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

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

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

From yzheng at openjdk.org  Tue Aug 22 06:30:27 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 22 Aug 2023 06:30:27 GMT
Subject: RFR: 8314688: VM build without C1 fails after JDK-8313372 [v2]
In-Reply-To: <S_n9xC2t1YW8WGPTxByhq0d4bqyM75VuWBrQrN6II0c=.6357e868-bdab-40e3-8fa6-ab48950e4b94@github.com>
References: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
 <S_n9xC2t1YW8WGPTxByhq0d4bqyM75VuWBrQrN6II0c=.6357e868-bdab-40e3-8fa6-ab48950e4b94@github.com>
Message-ID: <TCY0-Z368ysbhDUDG3Ysn3n5OKg7XxLtY4IteEH2HvI=.4e9cd0f4-db93-4bda-bb7c-c3326ca75473@github.com>

On Tue, 22 Aug 2023 03:47:51 GMT, xpbob <duke at openjdk.org> wrote:

>> [8314688: VM build without C1 fails after JDK-8313372]
>> 
>> ./configure --with-jvm-features=-compiler1 --with-debug-level=release
>> make images JOBS=32
>> 
>> 
>> jvmciCompilerToVMInit.o:make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:252: more undefined references to `Compiler::is_intrinsic_supported(vmIntrinsicID)' follow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code format

Looks good to me. Thanks for fixing this!

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

Marked as reviewed by yzheng (no project role).

PR Review: https://git.openjdk.org/jdk/pull/15376#pullrequestreview-1588504298

From haosun at openjdk.org  Tue Aug 22 06:34:27 2023
From: haosun at openjdk.org (Hao Sun)
Date: Tue, 22 Aug 2023 06:34:27 GMT
Subject: RFR: 8314688: VM build without C1 fails after JDK-8313372 [v2]
In-Reply-To: <S_n9xC2t1YW8WGPTxByhq0d4bqyM75VuWBrQrN6II0c=.6357e868-bdab-40e3-8fa6-ab48950e4b94@github.com>
References: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
 <S_n9xC2t1YW8WGPTxByhq0d4bqyM75VuWBrQrN6II0c=.6357e868-bdab-40e3-8fa6-ab48950e4b94@github.com>
Message-ID: <LHbf7Pglnz5qPwsB_sSa-l6Qj7dpTKQmB3glx4DE8d8=.6e8d0954-afbe-4796-be14-23f3280d4297@github.com>

On Tue, 22 Aug 2023 03:47:51 GMT, xpbob <duke at openjdk.org> wrote:

>> [8314688: VM build without C1 fails after JDK-8313372]
>> 
>> ./configure --with-jvm-features=-compiler1 --with-debug-level=release
>> make images JOBS=32
>> 
>> 
>> jvmciCompilerToVMInit.o:make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:252: more undefined references to `Compiler::is_intrinsic_supported(vmIntrinsicID)' follow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code format

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 230:

> 228: static jboolean is_c1_supported(vmIntrinsics::ID id){
> 229:     jboolean supported = false;
> 230: #ifdef COMPILER1

Header `c1/c1_Compiler.hpp` at line 25 was introduced in JDK-8313372.
I suggest adding `#ifdef COMPILER1` directive for this header as well.

The same to the C2 case, i.e. header `opto/c2compiler.hpp`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15376#discussion_r1301035371

From duke at openjdk.org  Tue Aug 22 06:59:58 2023
From: duke at openjdk.org (xpbob)
Date: Tue, 22 Aug 2023 06:59:58 GMT
Subject: RFR: 8314688: VM build without C1 fails after JDK-8313372 [v3]
In-Reply-To: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
References: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
Message-ID: <ALn7HuMPDgDTsP4Sl0hInS80Ajj_9fpa91GPZyQWezQ=.5e6f54eb-cee7-4e67-9c9b-9e594b10e4dd@github.com>

> [8314688: VM build without C1 fails after JDK-8313372]
> 
> ./configure --with-jvm-features=-compiler1 --with-debug-level=release
> make images JOBS=32
> 
> 
> jvmciCompilerToVMInit.o:make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:252: more undefined references to `Compiler::is_intrinsic_supported(vmIntrinsicID)' follow

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

  add ifdef for header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15376/files
  - new: https://git.openjdk.org/jdk/pull/15376/files/6937badb..584aa573

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

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

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

From duke at openjdk.org  Tue Aug 22 07:07:28 2023
From: duke at openjdk.org (xpbob)
Date: Tue, 22 Aug 2023 07:07:28 GMT
Subject: RFR: 8314688: VM build without C1 fails after JDK-8313372 [v2]
In-Reply-To: <TCY0-Z368ysbhDUDG3Ysn3n5OKg7XxLtY4IteEH2HvI=.4e9cd0f4-db93-4bda-bb7c-c3326ca75473@github.com>
References: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
 <S_n9xC2t1YW8WGPTxByhq0d4bqyM75VuWBrQrN6II0c=.6357e868-bdab-40e3-8fa6-ab48950e4b94@github.com>
 <TCY0-Z368ysbhDUDG3Ysn3n5OKg7XxLtY4IteEH2HvI=.4e9cd0f4-db93-4bda-bb7c-c3326ca75473@github.com>
Message-ID: <-0DMjS0b2mu1NEai0S_i5AF19RlPgPucejSJVx_e-qw=.639c8c71-45f4-4c88-a601-3f242201a62e@github.com>

On Tue, 22 Aug 2023 06:27:15 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code format
>
> Looks good to me. Thanks for fixing this!

@mur47x111 @shqking 
Thanks for the review,The code has been updated
add #ifdef for the header

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

PR Comment: https://git.openjdk.org/jdk/pull/15376#issuecomment-1687593620

From dnsimon at openjdk.org  Tue Aug 22 08:40:28 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 22 Aug 2023 08:40:28 GMT
Subject: RFR: 8314688: VM build without C1 fails after JDK-8313372 [v3]
In-Reply-To: <ALn7HuMPDgDTsP4Sl0hInS80Ajj_9fpa91GPZyQWezQ=.5e6f54eb-cee7-4e67-9c9b-9e594b10e4dd@github.com>
References: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
 <ALn7HuMPDgDTsP4Sl0hInS80Ajj_9fpa91GPZyQWezQ=.5e6f54eb-cee7-4e67-9c9b-9e594b10e4dd@github.com>
Message-ID: <HLcZTqCTy92Fe3iQAT-ECurxzvTF5HZzXK_67_EBx2k=.d2bbb53c-3356-4ebe-a396-9e172058c61c@github.com>

On Tue, 22 Aug 2023 06:59:58 GMT, xpbob <duke at openjdk.org> wrote:

>> [8314688: VM build without C1 fails after JDK-8313372]
>> 
>> ./configure --with-jvm-features=-compiler1 --with-debug-level=release
>> make images JOBS=32
>> 
>> 
>> jvmciCompilerToVMInit.o:make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:252: more undefined references to `Compiler::is_intrinsic_supported(vmIntrinsicID)' follow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add ifdef for header

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15376#pullrequestreview-1588825458

From haosun at openjdk.org  Tue Aug 22 08:51:31 2023
From: haosun at openjdk.org (Hao Sun)
Date: Tue, 22 Aug 2023 08:51:31 GMT
Subject: RFR: 8314688: VM build without C1 fails after JDK-8313372 [v3]
In-Reply-To: <ALn7HuMPDgDTsP4Sl0hInS80Ajj_9fpa91GPZyQWezQ=.5e6f54eb-cee7-4e67-9c9b-9e594b10e4dd@github.com>
References: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
 <ALn7HuMPDgDTsP4Sl0hInS80Ajj_9fpa91GPZyQWezQ=.5e6f54eb-cee7-4e67-9c9b-9e594b10e4dd@github.com>
Message-ID: <U4D5GCO7WfO8NZoHeQkTxL2ad-5D0QVXzHR0djAAmyc=.bc129da8-381f-4fc9-8843-21d9b652c12a@github.com>

On Tue, 22 Aug 2023 06:59:58 GMT, xpbob <duke at openjdk.org> wrote:

>> [8314688: VM build without C1 fails after JDK-8313372]
>> 
>> ./configure --with-jvm-features=-compiler1 --with-debug-level=release
>> make images JOBS=32
>> 
>> 
>> jvmciCompilerToVMInit.o:make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:252: more undefined references to `Compiler::is_intrinsic_supported(vmIntrinsicID)' follow
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add ifdef for header

Thanks for your update. LGTM.

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

Marked as reviewed by haosun (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15376#pullrequestreview-1588854306

From duke at openjdk.org  Tue Aug 22 08:51:31 2023
From: duke at openjdk.org (xpbob)
Date: Tue, 22 Aug 2023 08:51:31 GMT
Subject: RFR: 8314688: VM build without C1 fails after JDK-8313372 [v3]
In-Reply-To: <HLcZTqCTy92Fe3iQAT-ECurxzvTF5HZzXK_67_EBx2k=.d2bbb53c-3356-4ebe-a396-9e172058c61c@github.com>
References: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
 <ALn7HuMPDgDTsP4Sl0hInS80Ajj_9fpa91GPZyQWezQ=.5e6f54eb-cee7-4e67-9c9b-9e594b10e4dd@github.com>
 <HLcZTqCTy92Fe3iQAT-ECurxzvTF5HZzXK_67_EBx2k=.d2bbb53c-3356-4ebe-a396-9e172058c61c@github.com>
Message-ID: <F5edcpXkXu6OpHM3g6vmWSasLxFB2w27n4qOsSGutGk=.e4558ef9-c00c-4841-a33d-1fa744033be5@github.com>

On Tue, 22 Aug 2023 08:37:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add ifdef for header
>
> Marked as reviewed by dnsimon (Reviewer).

@dougxc Thanks for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/15376#issuecomment-1687752636

From duke at openjdk.org  Tue Aug 22 09:24:36 2023
From: duke at openjdk.org (xpbob)
Date: Tue, 22 Aug 2023 09:24:36 GMT
Subject: Integrated: 8314688: VM build without C1 fails after JDK-8313372
In-Reply-To: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
References: <N6YvQcMxMjAYaYuKBvAxMnbQHrYx077nIQdJOjwRgQ8=.992225c6-dd33-464b-aab2-3afe8d6c2d8d@github.com>
Message-ID: <NaBnduO2e9n2bFuI2Jwlmh3s7Y14YKJwlr4d1qFRcmA=.03dd77ce-a08f-4608-ad99-e7b0c41b35dd@github.com>

On Tue, 22 Aug 2023 03:33:03 GMT, xpbob <duke at openjdk.org> wrote:

> [8314688: VM build without C1 fails after JDK-8313372]
> 
> ./configure --with-jvm-features=-compiler1 --with-debug-level=release
> make images JOBS=32
> 
> 
> jvmciCompilerToVMInit.o:make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:252: more undefined references to `Compiler::is_intrinsic_supported(vmIntrinsicID)' follow

This pull request has now been integrated.

Changeset: 3e1b1bf9
Author:    bobpengxie <bobpengxie at tencent.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e1b1bf94e7acf9717b837085e61fc05a7765de4
Stats:     22 lines in 1 file changed: 20 ins; 0 del; 2 mod

8314688: VM build without C1 fails after JDK-8313372

Reviewed-by: yzheng, dnsimon, haosun

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

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

From dnsimon at openjdk.org  Tue Aug 22 21:46:17 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 22 Aug 2023 21:46:17 GMT
Subject: RFR: 8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws unexpected
 ClassNotFoundException
Message-ID: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>

This PR restores the expected behavior prior to [JDK-8313421](https://bugs.openjdk.org/browse/JDK-8313421) whereby `HotSpotJVMCIRuntime.lookupType` throws `NoClassDefFoundError` instead of `ClassNotFoundException`.

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

Commit messages:
 - CompilerToVM.lookupType must throw NoClassDefFoundError instead of ClassNotFoundException

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

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

From never at openjdk.org  Wed Aug 23 00:23:21 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 23 Aug 2023 00:23:21 GMT
Subject: RFR: 8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws
 unexpected ClassNotFoundException
In-Reply-To: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
References: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
Message-ID: <763VIkdu5hSOm3jAGR0qs3NDdbOCiCn43lDgqKBa2F8=.3d2f9c00-6474-43bf-84a3-b4c92049b1b4@github.com>

On Tue, 22 Aug 2023 21:01:26 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR restores the expected behavior prior to [JDK-8313421](https://bugs.openjdk.org/browse/JDK-8313421) whereby `HotSpotJVMCIRuntime.lookupType` throws `NoClassDefFoundError` instead of `ClassNotFoundException`.

Looks good.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15393#pullrequestreview-1590518452

From dnsimon at openjdk.org  Wed Aug 23 09:11:33 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 23 Aug 2023 09:11:33 GMT
Subject: RFR: 8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws
 unexpected ClassNotFoundException [v2]
In-Reply-To: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
References: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
Message-ID: <RM7v87GwmCFBSh-5fUezwcDC_u3fzR4F5KEcWoe4y-8=.c46da063-6255-4275-b879-097df309efd2@github.com>

> This PR restores the expected behavior prior to [JDK-8313421](https://bugs.openjdk.org/browse/JDK-8313421) whereby `HotSpotJVMCIRuntime.lookupType` throws `NoClassDefFoundError` instead of `ClassNotFoundException`.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  fixed and expanded testing related to CompilerToVM.lookupType

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15393/files
  - new: https://git.openjdk.org/jdk/pull/15393/files/c62ba346..adf985d4

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

  Stats: 64 lines in 3 files changed: 41 ins; 4 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/15393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15393/head:pull/15393

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

From thartmann at openjdk.org  Wed Aug 23 09:11:38 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Aug 2023 09:11:38 GMT
Subject: RFR: 8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws
 unexpected ClassNotFoundException [v2]
In-Reply-To: <RM7v87GwmCFBSh-5fUezwcDC_u3fzR4F5KEcWoe4y-8=.c46da063-6255-4275-b879-097df309efd2@github.com>
References: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
 <RM7v87GwmCFBSh-5fUezwcDC_u3fzR4F5KEcWoe4y-8=.c46da063-6255-4275-b879-097df309efd2@github.com>
Message-ID: <LOScdgrdxvadFumZoI0OAD-_ioRr5eGy-VtH9UBagWs=.f14e0ad3-be85-4bc2-a7d4-b5f705225145@github.com>

On Wed, 23 Aug 2023 08:26:31 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR restores the expected behavior prior to [JDK-8313421](https://bugs.openjdk.org/browse/JDK-8313421) whereby `HotSpotJVMCIRuntime.lookupType` throws `NoClassDefFoundError` instead of `ClassNotFoundException`.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed and expanded testing related to CompilerToVM.lookupType

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15393#pullrequestreview-1590780972

From thartmann at openjdk.org  Wed Aug 23 09:11:46 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Aug 2023 09:11:46 GMT
Subject: RFR: 8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws
 unexpected ClassNotFoundException
In-Reply-To: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
References: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
Message-ID: <K5nhqjxXELkO2S6pmWHHZHtb-kHTTrFqX_-LGD115cw=.e9d4071f-5c3f-45d9-a441-b7efeaaf30de@github.com>

On Tue, 22 Aug 2023 21:01:26 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR restores the expected behavior prior to [JDK-8313421](https://bugs.openjdk.org/browse/JDK-8313421) whereby `HotSpotJVMCIRuntime.lookupType` throws `NoClassDefFoundError` instead of `ClassNotFoundException`.

Just wondering, should there be a regression test?

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

PR Comment: https://git.openjdk.org/jdk/pull/15393#issuecomment-1689308605

From dnsimon at openjdk.org  Wed Aug 23 09:11:50 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 23 Aug 2023 09:11:50 GMT
Subject: RFR: 8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws
 unexpected ClassNotFoundException
In-Reply-To: <K5nhqjxXELkO2S6pmWHHZHtb-kHTTrFqX_-LGD115cw=.e9d4071f-5c3f-45d9-a441-b7efeaaf30de@github.com>
References: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
 <K5nhqjxXELkO2S6pmWHHZHtb-kHTTrFqX_-LGD115cw=.e9d4071f-5c3f-45d9-a441-b7efeaaf30de@github.com>
Message-ID: <rXFHJcd4MUcz91hRZ8WmHHIhY7z6CNB841txffuklSA=.9c682ac2-5298-4601-9e87-f86e449e5399@github.com>

On Wed, 23 Aug 2023 05:34:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Just wondering, should there be a regression test?

Yes. The existing tests for `CompilerToVM.lookupType` needed to be adjusted and I expanded them to also test HotSpotJVMCIRuntime.lookupType`: adf985d4c9ba35d9d9d586fad503e0660eee9f91

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

PR Comment: https://git.openjdk.org/jdk/pull/15393#issuecomment-1689512846

From thartmann at openjdk.org  Wed Aug 23 09:28:07 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Aug 2023 09:28:07 GMT
Subject: RFR: 8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws
 unexpected ClassNotFoundException [v2]
In-Reply-To: <RM7v87GwmCFBSh-5fUezwcDC_u3fzR4F5KEcWoe4y-8=.c46da063-6255-4275-b879-097df309efd2@github.com>
References: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
 <RM7v87GwmCFBSh-5fUezwcDC_u3fzR4F5KEcWoe4y-8=.c46da063-6255-4275-b879-097df309efd2@github.com>
Message-ID: <Gu8gUrz2yPa6aqBShuNP4v7enat7alyiyfbRGVbNNso=.dc004282-fa66-4282-8ae9-e799bf18774c@github.com>

On Wed, 23 Aug 2023 09:11:33 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR restores the expected behavior prior to [JDK-8313421](https://bugs.openjdk.org/browse/JDK-8313421) whereby `HotSpotJVMCIRuntime.lookupType` throws `NoClassDefFoundError` instead of `ClassNotFoundException`.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed and expanded testing related to CompilerToVM.lookupType

Marked as reviewed by thartmann (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15393#pullrequestreview-1591140399

From dnsimon at openjdk.org  Thu Aug 24 10:15:37 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 24 Aug 2023 10:15:37 GMT
Subject: RFR: 8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws
 unexpected ClassNotFoundException [v2]
In-Reply-To: <RM7v87GwmCFBSh-5fUezwcDC_u3fzR4F5KEcWoe4y-8=.c46da063-6255-4275-b879-097df309efd2@github.com>
References: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
 <RM7v87GwmCFBSh-5fUezwcDC_u3fzR4F5KEcWoe4y-8=.c46da063-6255-4275-b879-097df309efd2@github.com>
Message-ID: <50C6i8OX3DkF74vH7x09KUDVK_OiAziFsl1GpYl3EYo=.4817de99-a8e3-47cf-a4d4-6bccbaa8159b@github.com>

On Wed, 23 Aug 2023 09:11:33 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR restores the expected behavior prior to [JDK-8313421](https://bugs.openjdk.org/browse/JDK-8313421) whereby `HotSpotJVMCIRuntime.lookupType` throws `NoClassDefFoundError` instead of `ClassNotFoundException`.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed and expanded testing related to CompilerToVM.lookupType

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/15393#issuecomment-1691398807

From dnsimon at openjdk.org  Thu Aug 24 10:15:39 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 24 Aug 2023 10:15:39 GMT
Subject: Integrated: 8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws
 unexpected ClassNotFoundException
In-Reply-To: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
References: <JhgdyphhwG2wxoIHPAVTD1eHhFmYBoI2YBbX17XNYe8=.0f8db050-d77f-45b2-bef7-5ece66af70ea@github.com>
Message-ID: <wlX603Zsa8lQ7d0hVpSDK53LZg6c2x_X7pPv56nnL6Y=.b02b1ca7-4d07-4480-8ac6-19cf98c0a6d0@github.com>

On Tue, 22 Aug 2023 21:01:26 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR restores the expected behavior prior to [JDK-8313421](https://bugs.openjdk.org/browse/JDK-8313421) whereby `HotSpotJVMCIRuntime.lookupType` throws `NoClassDefFoundError` instead of `ClassNotFoundException`.

This pull request has now been integrated.

Changeset: 75e19e0d
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75e19e0d5e6a705bcd10a9f9afbb6fdc3939adbb
Stats:     69 lines in 5 files changed: 41 ins; 7 del; 21 mod

8314819: [JVMCI] HotSpotJVMCIRuntime.lookupType throws unexpected ClassNotFoundException

Reviewed-by: never, thartmann

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

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

From jiefu at openjdk.org  Thu Aug 24 14:24:39 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 24 Aug 2023 14:24:39 GMT
Subject: RFR: 8314951: VM build without C2 still fails after JDK-8313530
Message-ID: <QU3U3eZ9MuUYV5QBvGf8rdyGDBuXvYx8yDRfGvN0APs=.c84b2432-b0ca-4eb6-b7d2-f6c6bef27d18@github.com>

JDK-8313530 fixed the release VM build but the debug VM build would still fail.
This patch fix the debug VM build failure.
Thanks.

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

Commit messages:
 - 8314951: VM build without C2 still fails after JDK-8313530

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

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

From dnsimon at openjdk.org  Thu Aug 24 14:35:28 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 24 Aug 2023 14:35:28 GMT
Subject: RFR: 8314951: VM build without C2 still fails after JDK-8313530
In-Reply-To: <QU3U3eZ9MuUYV5QBvGf8rdyGDBuXvYx8yDRfGvN0APs=.c84b2432-b0ca-4eb6-b7d2-f6c6bef27d18@github.com>
References: <QU3U3eZ9MuUYV5QBvGf8rdyGDBuXvYx8yDRfGvN0APs=.c84b2432-b0ca-4eb6-b7d2-f6c6bef27d18@github.com>
Message-ID: <FH__GWX9pofnaUaLGMehfWH-gIomga48ba6QUb9P4Xs=.bba5830a-d7ef-4ffd-87cc-c2002d497219@github.com>

On Thu, 24 Aug 2023 14:16:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> JDK-8313530 fixed the release VM build but the debug VM build would still fail.
> This patch fix the debug VM build failure.
> Thanks.

Marked as reviewed by dnsimon (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15419#pullrequestreview-1593762549

From kvn at openjdk.org  Thu Aug 24 20:26:08 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Aug 2023 20:26:08 GMT
Subject: RFR: 8314951: VM build without C2 still fails after JDK-8313530
In-Reply-To: <QU3U3eZ9MuUYV5QBvGf8rdyGDBuXvYx8yDRfGvN0APs=.c84b2432-b0ca-4eb6-b7d2-f6c6bef27d18@github.com>
References: <QU3U3eZ9MuUYV5QBvGf8rdyGDBuXvYx8yDRfGvN0APs=.c84b2432-b0ca-4eb6-b7d2-f6c6bef27d18@github.com>
Message-ID: <bBb9BnAI4a0bi0y8YkoeKiSvWTE_93Di9ZrZfTHnGUc=.0203a7e4-bfdd-4565-a901-7e3f9a2e2997@github.com>

On Thu, 24 Aug 2023 14:16:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> JDK-8313530 fixed the release VM build but the debug VM build would still fail.
> This patch fix the debug VM build failure.
> Thanks.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15419#pullrequestreview-1594399395

From jiefu at openjdk.org  Fri Aug 25 05:02:19 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 25 Aug 2023 05:02:19 GMT
Subject: RFR: 8314951: VM build without C2 still fails after JDK-8313530
In-Reply-To: <FH__GWX9pofnaUaLGMehfWH-gIomga48ba6QUb9P4Xs=.bba5830a-d7ef-4ffd-87cc-c2002d497219@github.com>
References: <QU3U3eZ9MuUYV5QBvGf8rdyGDBuXvYx8yDRfGvN0APs=.c84b2432-b0ca-4eb6-b7d2-f6c6bef27d18@github.com>
 <FH__GWX9pofnaUaLGMehfWH-gIomga48ba6QUb9P4Xs=.bba5830a-d7ef-4ffd-87cc-c2002d497219@github.com>
Message-ID: <KfGcL5Lay6dZv96FWqcUzV0l0IPer6VZmyirzekHgv4=.f6b4b5e6-88f0-4ae8-b1f2-b6adaac03401@github.com>

On Thu, 24 Aug 2023 14:32:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> JDK-8313530 fixed the release VM build but the debug VM build would still fail.
>> This patch fix the debug VM build failure.
>> Thanks.
>
> Marked as reviewed by dnsimon (Reviewer).

Thanks @dougxc and @vnkozlov for your review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15419#issuecomment-1692758604

From jiefu at openjdk.org  Fri Aug 25 05:02:20 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 25 Aug 2023 05:02:20 GMT
Subject: Integrated: 8314951: VM build without C2 still fails after JDK-8313530
In-Reply-To: <QU3U3eZ9MuUYV5QBvGf8rdyGDBuXvYx8yDRfGvN0APs=.c84b2432-b0ca-4eb6-b7d2-f6c6bef27d18@github.com>
References: <QU3U3eZ9MuUYV5QBvGf8rdyGDBuXvYx8yDRfGvN0APs=.c84b2432-b0ca-4eb6-b7d2-f6c6bef27d18@github.com>
Message-ID: <RudtVNGqmqNnyhv1WZKD1yK1z_FDPL8ZNlStkO8Cuxs=.63988e98-7e41-44e1-8d20-14cbfdb48b0a@github.com>

On Thu, 24 Aug 2023 14:16:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> JDK-8313530 fixed the release VM build but the debug VM build would still fail.
> This patch fix the debug VM build failure.
> Thanks.

This pull request has now been integrated.

Changeset: d0240591
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d02405917406a355a11741bb278ea58c3a4642fb
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8314951: VM build without C2 still fails after JDK-8313530

Reviewed-by: dnsimon, kvn

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

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

From tschatzl at openjdk.org  Tue Aug 29 09:10:18 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Aug 2023 09:10:18 GMT
Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of
 HeapRegion
In-Reply-To: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
Message-ID: <ExPAs1HbHiHQVcUb-hAwtpOn4pT8qgEZl7uoXCVqRSc=.eff329b0-be6c-4d84-adfa-84e6d542a5d8@github.com>

On Mon, 21 Aug 2023 12:25:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Use unsigned type for heap-region-size related shifts in HeapRegion.
>  
> Test: tier1-3

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp line 161:

> 159:     __ move(xor_res, xor_shift_res);
> 160:     __ unsigned_shift_right(xor_shift_res,
> 161:                             LIR_OprFact::intConst(static_cast<jint>(HeapRegion::LogOfHRGrainBytes)),

One could maybe argue that this should be a `checked_cast`, but given that the value bounds are known there is no point...

src/hotspot/share/gc/g1/g1Arguments.cpp line 137:

> 135:   uint region_size_log_mb = HeapRegion::LogOfHRGrainBytes > LOG_M
> 136:                           ? HeapRegion::LogOfHRGrainBytes - LOG_M
> 137:                           : 0;

I would just assert that `HeapRegion::LogOfHRGrainBytes >= LOG_M` here. People messing with with minimum region size would need to check this code anyway.

Further, `LOG_M` should probably be calculated as `log2_exact(HeapRegion::min_size())` instead of using the constant directly (and renamed appropriately, something like `Log[Of]MinHeapRegionSize/GrainBytes`).

Then there would be no need to do the maximum calculation (my original suggestion would have been `MAX2(HeapRegion::LogOfHRGrainBytes - LOG_M, 0u)` btw)

src/hotspot/share/gc/g1/g1Arguments.cpp line 140:

> 138: 
> 139:   if (FLAG_IS_DEFAULT(G1RemSetArrayOfCardsEntries)) {
> 140:     uint max_cards_in_inline_ptr = G1CardSetConfiguration::max_cards_in_inline_ptr(HeapRegion::LogCardsPerRegion);

Not sure how this change has anything to do with -Wconversion, but okay :)

src/hotspot/share/gc/g1/g1CardTable.inline.hpp line 34:

> 32: inline uint G1CardTable::region_idx_for(CardValue* p) {
> 33:   size_t const card_idx = pointer_delta(p, _byte_map, sizeof(CardValue));
> 34:   return (uint)(card_idx >> HeapRegion::LogCardsPerRegion);

Not sure how this change has anything to do with -Wconversion but okay :)

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 820:

> 818: 
> 819: #define VM_STRUCTS_JVMCI_G1GC(nonstatic_field, static_field) \
> 820:   static_field(HeapRegion, LogOfHRGrainBytes, uint32_t)

Suggestion:

  static_field(HeapRegion, LogOfHRGrainBytes, uint)


Seems to compile just fine here.

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

PR Review: https://git.openjdk.org/jdk/pull/15360#pullrequestreview-1599784043
PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308457638
PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308395646
PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308396907
PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308396990
PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308423061

From ayang at openjdk.org  Tue Aug 29 09:23:10 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 29 Aug 2023 09:23:10 GMT
Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of
 HeapRegion
In-Reply-To: <ExPAs1HbHiHQVcUb-hAwtpOn4pT8qgEZl7uoXCVqRSc=.eff329b0-be6c-4d84-adfa-84e6d542a5d8@github.com>
References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
 <ExPAs1HbHiHQVcUb-hAwtpOn4pT8qgEZl7uoXCVqRSc=.eff329b0-be6c-4d84-adfa-84e6d542a5d8@github.com>
Message-ID: <APXKFRrWI4aqFNLFFBWMv7zcodsd_UqX4pYPPh3wRtc=.16fc078f-bcb0-4047-a05f-1f414ddea155@github.com>

On Tue, 29 Aug 2023 08:38:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Use unsigned type for heap-region-size related shifts in HeapRegion.
>>  
>> Test: tier1-3
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 820:
> 
>> 818: 
>> 819: #define VM_STRUCTS_JVMCI_G1GC(nonstatic_field, static_field) \
>> 820:   static_field(HeapRegion, LogOfHRGrainBytes, uint32_t)
> 
> Suggestion:
> 
>   static_field(HeapRegion, LogOfHRGrainBytes, uint)
> 
> 
> Seems to compile just fine here.

That was my original attempt, but JVMCI related tests failed with `uint`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308475030

From ayang at openjdk.org  Tue Aug 29 13:21:35 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 29 Aug 2023 13:21:35 GMT
Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of
 HeapRegion [v2]
In-Reply-To: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
Message-ID: <CO7OwXA7kLzvY26S7QFNJL4HUnbLEaZDN4jctN2syPg=.91481333-8f5a-4d0a-b3de-972c6ae2719a@github.com>

> Use unsigned type for heap-region-size related shifts in HeapRegion.
>  
> Test: tier1-3

Albert Mingkun Yang 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:

 - review
 - Merge branch 'master' into g1-heap-region-log-uint
 - g1-heap-region-log-uint

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15360/files
  - new: https://git.openjdk.org/jdk/pull/15360/files/26e1e298..49866dac

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

  Stats: 7641 lines in 350 files changed: 4996 ins; 1034 del; 1611 mod
  Patch: https://git.openjdk.org/jdk/pull/15360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15360/head:pull/15360

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

From ayang at openjdk.org  Tue Aug 29 13:21:36 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 29 Aug 2023 13:21:36 GMT
Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of
 HeapRegion [v2]
In-Reply-To: <ExPAs1HbHiHQVcUb-hAwtpOn4pT8qgEZl7uoXCVqRSc=.eff329b0-be6c-4d84-adfa-84e6d542a5d8@github.com>
References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
 <ExPAs1HbHiHQVcUb-hAwtpOn4pT8qgEZl7uoXCVqRSc=.eff329b0-be6c-4d84-adfa-84e6d542a5d8@github.com>
Message-ID: <IQneCoNVfEVEuaP4YDg0hTCBjbdQ9ONcEzxcRsmGHT4=.ce5b900b-f583-4505-a64d-c90deaf62517@github.com>

On Tue, 29 Aug 2023 08:16:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Albert Mingkun Yang 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:
>> 
>>  - review
>>  - Merge branch 'master' into g1-heap-region-log-uint
>>  - g1-heap-region-log-uint
>
> src/hotspot/share/gc/g1/g1Arguments.cpp line 137:
> 
>> 135:   uint region_size_log_mb = HeapRegion::LogOfHRGrainBytes > LOG_M
>> 136:                           ? HeapRegion::LogOfHRGrainBytes - LOG_M
>> 137:                           : 0;
> 
> I would just assert that `HeapRegion::LogOfHRGrainBytes >= LOG_M` here. People messing with with minimum region size would need to check this code anyway.
> 
> Further, `LOG_M` should probably be calculated as `log2_exact(HeapRegion::min_size())` instead of using the constant directly (and renamed appropriately, something like `Log[Of]MinHeapRegionSize/GrainBytes`).
> 
> Then there would be no need to do the maximum calculation (my original suggestion would have been `MAX2(HeapRegion::LogOfHRGrainBytes - LOG_M, 0u)` btw)

Checking how it's used around `G1RemSetArrayOfCardsEntriesBase`, `log_m` is more about 1MB. The very fact that min-heap-region is 1M seems an accident. Kept the original name and added assertion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308804146

From tschatzl at openjdk.org  Tue Aug 29 14:38:12 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 29 Aug 2023 14:38:12 GMT
Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of
 HeapRegion [v2]
In-Reply-To: <CO7OwXA7kLzvY26S7QFNJL4HUnbLEaZDN4jctN2syPg=.91481333-8f5a-4d0a-b3de-972c6ae2719a@github.com>
References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
 <CO7OwXA7kLzvY26S7QFNJL4HUnbLEaZDN4jctN2syPg=.91481333-8f5a-4d0a-b3de-972c6ae2719a@github.com>
Message-ID: <Vw0IXYOkHxnJxDhBGZ6OeL4dntNDaiIaAU7Fe3gAfxw=.69ff7815-206c-4aaa-8ea7-df05f7c77343@github.com>

On Tue, 29 Aug 2023 13:21:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use unsigned type for heap-region-size related shifts in HeapRegion.
>>  
>> Test: tier1-3
>
> Albert Mingkun Yang 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:
> 
>  - review
>  - Merge branch 'master' into g1-heap-region-log-uint
>  - g1-heap-region-log-uint

Lgtm.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15360#pullrequestreview-1600600828
PR Review: https://git.openjdk.org/jdk/pull/15360#pullrequestreview-1600601295

From iwalulya at openjdk.org  Tue Aug 29 16:09:12 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 29 Aug 2023 16:09:12 GMT
Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of
 HeapRegion [v2]
In-Reply-To: <CO7OwXA7kLzvY26S7QFNJL4HUnbLEaZDN4jctN2syPg=.91481333-8f5a-4d0a-b3de-972c6ae2719a@github.com>
References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
 <CO7OwXA7kLzvY26S7QFNJL4HUnbLEaZDN4jctN2syPg=.91481333-8f5a-4d0a-b3de-972c6ae2719a@github.com>
Message-ID: <A9P0cT-_kRVgoZoSahlHO8wHlxiYbzXJ1dtDf-L5B1g=.5e9d4fe2-12c0-4edb-921b-a88e69e896fa@github.com>

On Tue, 29 Aug 2023 13:21:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use unsigned type for heap-region-size related shifts in HeapRegion.
>>  
>> Test: tier1-3
>
> Albert Mingkun Yang 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:
> 
>  - review
>  - Merge branch 'master' into g1-heap-region-log-uint
>  - g1-heap-region-log-uint

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15360#pullrequestreview-1600803752

From ayang at openjdk.org  Wed Aug 30 09:40:20 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Aug 2023 09:40:20 GMT
Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of
 HeapRegion [v2]
In-Reply-To: <CO7OwXA7kLzvY26S7QFNJL4HUnbLEaZDN4jctN2syPg=.91481333-8f5a-4d0a-b3de-972c6ae2719a@github.com>
References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
 <CO7OwXA7kLzvY26S7QFNJL4HUnbLEaZDN4jctN2syPg=.91481333-8f5a-4d0a-b3de-972c6ae2719a@github.com>
Message-ID: <bh1NbIqxECEHmWmRTSX-Nf5XFGWJEAofJnT7KgHzeZo=.d020c006-fa59-464d-8863-f44f4b5ada41@github.com>

On Tue, 29 Aug 2023 13:21:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use unsigned type for heap-region-size related shifts in HeapRegion.
>>  
>> Test: tier1-3
>
> Albert Mingkun Yang 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:
> 
>  - review
>  - Merge branch 'master' into g1-heap-region-log-uint
>  - g1-heap-region-log-uint

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15360#issuecomment-1698828094

From ayang at openjdk.org  Wed Aug 30 09:40:21 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 30 Aug 2023 09:40:21 GMT
Subject: Integrated: 8314651: G1: Fix -Wconversion warnings in static fields of
 HeapRegion
In-Reply-To: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com>
Message-ID: <uDO3RNYIoECnVKX6-8L7QeHO4bt-5Bmu-fBSfePxWuw=.47ddbf61-fd5e-4469-82b2-269b70bf41ce@github.com>

On Mon, 21 Aug 2023 12:25:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Use unsigned type for heap-region-size related shifts in HeapRegion.
>  
> Test: tier1-3

This pull request has now been integrated.

Changeset: cb3f9680
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb3f9680d35f2afbd973c946ad4ccf94f30fffc9
Stats:     24 lines in 9 files changed: 4 ins; 4 del; 16 mod

8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion

Reviewed-by: tschatzl, iwalulya

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

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