From jcking at openjdk.org  Wed Feb  1 15:26:27 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 1 Feb 2023 15:26:27 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
Message-ID: <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>

> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that rely on testing compressed oops or compressed class pointers. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
> 
> **Suppressing:**
> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
> 
> **Caveats:**
> - `UseCompressedOops` and `UseCompressedClassPointers` are forced to false when LSan is enabled. This is necessary to ensure all pointers to memory which could possible container pointers to malloc memory are property aligned, which is an LSan requirement.
> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. This is due to the other caveats. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
> - There are a series of tests that are upset due to the above flags being forced false, as they rely on the arguments being supported. In the future ideally these tests would be skipped nicely when LSan is enabled.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Support CDS
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12229/files
  - new: https://git.openjdk.org/jdk/pull/12229/files/15f060e8..4559ef4c

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

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

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


From jcking at openjdk.org  Wed Feb  1 15:26:27 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 1 Feb 2023 15:26:27 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot
In-Reply-To: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
Message-ID: <uX0802rWMm1YDbnBD2Rs13SgVXI8HkGlI5b0wFvDIx0=.a1dd95a6-ab7f-45f4-aed5-a8085a618199@github.com>

On Thu, 26 Jan 2023 17:33:28 GMT, Justin King <jcking at openjdk.org> wrote:

> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that rely on testing compressed oops or compressed class pointers. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
> 
> **Suppressing:**
> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
> 
> **Caveats:**
> - `UseCompressedOops` and `UseCompressedClassPointers` are forced to false when LSan is enabled. This is necessary to ensure all pointers to memory which could possible container pointers to malloc memory are property aligned, which is an LSan requirement.
> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. This is due to the other caveats. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
> - There are a series of tests that are upset due to the above flags being forced false, as they rely on the arguments being supported. In the future ideally these tests would be skipped nicely when LSan is enabled.

Updated. Was able to get it cooperating with CDS.

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

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


From mikael at openjdk.org  Wed Feb  1 17:46:49 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 1 Feb 2023 17:46:49 GMT
Subject: RFR: 8301393: Include cdb in the Windows devkit
In-Reply-To: <ypLjnldiuxejQ0CNGVehv5pWGEE0NGPqBKYTo2Nt8ak=.1e1adea2-4b52-4314-83e9-273a7ac0bdf0@github.com>
References: <ypLjnldiuxejQ0CNGVehv5pWGEE0NGPqBKYTo2Nt8ak=.1e1adea2-4b52-4314-83e9-273a7ac0bdf0@github.com>
Message-ID: <3i0iDZ1vavi-RvYru2kaDtzQHgEUV-Wshkdyc6KrWkc=.e3b806bf-340b-4d52-87d8-1ef4b5dc0e9f@github.com>

On Tue, 31 Jan 2023 21:44:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch modifies the windows devkit, optionally adding the debugger tools from the Windows SDK. These tools include `cdb` which the failure_handler uses to extract information when tests time out.

Update copyright year

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

Marked as reviewed by mikael (Reviewer).

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


From erikj at openjdk.org  Wed Feb  1 18:39:14 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 1 Feb 2023 18:39:14 GMT
Subject: RFR: 8301393: Include cdb in the Windows devkit [v2]
In-Reply-To: <ypLjnldiuxejQ0CNGVehv5pWGEE0NGPqBKYTo2Nt8ak=.1e1adea2-4b52-4314-83e9-273a7ac0bdf0@github.com>
References: <ypLjnldiuxejQ0CNGVehv5pWGEE0NGPqBKYTo2Nt8ak=.1e1adea2-4b52-4314-83e9-273a7ac0bdf0@github.com>
Message-ID: <Lja97r0Z29YAp6WHci2PMInJUb2ICuxxf49RtpPUNsU=.4902d186-fec6-41f3-a549-76fab73145d3@github.com>

> This patch modifies the windows devkit, optionally adding the debugger tools from the Windows SDK. These tools include `cdb` which the failure_handler uses to extract information when tests time out.

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

  Copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12353/files
  - new: https://git.openjdk.org/jdk/pull/12353/files/7acf6cf5..e131b4aa

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

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

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


From mikael at openjdk.org  Wed Feb  1 19:20:51 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 1 Feb 2023 19:20:51 GMT
Subject: RFR: 8301393: Include cdb in the Windows devkit [v2]
In-Reply-To: <Lja97r0Z29YAp6WHci2PMInJUb2ICuxxf49RtpPUNsU=.4902d186-fec6-41f3-a549-76fab73145d3@github.com>
References: <ypLjnldiuxejQ0CNGVehv5pWGEE0NGPqBKYTo2Nt8ak=.1e1adea2-4b52-4314-83e9-273a7ac0bdf0@github.com>
 <Lja97r0Z29YAp6WHci2PMInJUb2ICuxxf49RtpPUNsU=.4902d186-fec6-41f3-a549-76fab73145d3@github.com>
Message-ID: <l9-kPn1ganYdfX3BhO8-Yd1de5_yY2zuZHHsGA1EOSE=.3b0dbfce-045a-40ae-983f-3fc31727d983@github.com>

On Wed, 1 Feb 2023 18:39:14 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This patch modifies the windows devkit, optionally adding the debugger tools from the Windows SDK. These tools include `cdb` which the failure_handler uses to extract information when tests time out.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year

Marked as reviewed by mikael (Reviewer).

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

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


From erikj at openjdk.org  Wed Feb  1 21:08:05 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 1 Feb 2023 21:08:05 GMT
Subject: Integrated: 8301393: Include cdb in the Windows devkit
In-Reply-To: <ypLjnldiuxejQ0CNGVehv5pWGEE0NGPqBKYTo2Nt8ak=.1e1adea2-4b52-4314-83e9-273a7ac0bdf0@github.com>
References: <ypLjnldiuxejQ0CNGVehv5pWGEE0NGPqBKYTo2Nt8ak=.1e1adea2-4b52-4314-83e9-273a7ac0bdf0@github.com>
Message-ID: <IJjQwtPQbQqj1az5mvcoSPtusOMKLo1_rKxJEf3CByM=.87ec6036-3f2a-4eb7-9370-79d5b884630d@github.com>

On Tue, 31 Jan 2023 21:44:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch modifies the windows devkit, optionally adding the debugger tools from the Windows SDK. These tools include `cdb` which the failure_handler uses to extract information when tests time out.

This pull request has now been integrated.

Changeset: 960c3931
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/960c3931337b314417ad33d8a775ee3e251692d7
Stats:     36 lines in 2 files changed: 31 ins; 0 del; 5 mod

8301393: Include cdb in the Windows devkit

Reviewed-by: mikael

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

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


From dholmes at openjdk.org  Thu Feb  2 06:13:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Feb 2023 06:13:29 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
Message-ID: <ka7iNEhBDJZ28wEcaAnfiNqCoJV2vmkyOz7O0xR1YCs=.5b5e81a5-d77e-41e3-b16e-a97331238b17@github.com>

On Wed, 1 Feb 2023 15:26:27 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that rely on testing compressed oops or compressed class pointers. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - `UseCompressedOops` and `UseCompressedClassPointers` are forced to false when LSan is enabled. This is necessary to ensure all pointers to memory which could possible container pointers to malloc memory are property aligned, which is an LSan requirement.
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. This is due to the other caveats. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>> - There are a series of tests that are upset due to the above flags being forced false, as they rely on the arguments being supported. In the future ideally these tests would be skipped nicely when LSan is enabled.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support CDS
>   
>   Signed-off-by: Justin King <jcking at google.com>

make/data/lsan/lsan_default_options.c line 49:

> 47: // extremely early during library loading, before main is called.  We need to override the default
> 48: // options because LSan will perform leak checking at program exit. Unfortunately Hotspot does not
> 49: // shutdown cleaning at the moment and some leaks occur, we want to ignore these. Instead we

s/cleaning/cleanly/

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

> 3977:   // LSAN relies on pointers to be natively aligned. Using compressed class pointers breaks this
> 3978:   // expectation and results in nondeterministic leak reports.
> 3979:   if (FLAG_SET_CMDLINE(UseCompressedOops, false) != JVMFlag::SUCCESS) {

This positioning doesn't look right. There are a number of inter-dependencies on the compressed oops flags and I don't think you can just turn them off here. Surely `Arguments::set_use_compressed_oops()` is where this needs to be done?

src/hotspot/share/runtime/init.cpp line 132:

> 130:     VirtualSpaceSummary summary = Universe::heap()->create_heap_space_summary();
> 131:     LSAN_REGISTER_ROOT_REGION(summary.start(), summary.reserved_size());
> 132:   }

Why is this unconditional? I expected it to be in `#ifdef LEAK_SANITIZER`

src/hotspot/share/runtime/init.cpp line 198:

> 196:       VirtualSpaceSummary summary = Universe::heap()->create_heap_space_summary();
> 197:       LSAN_UNREGISTER_ROOT_REGION(summary.start(), summary.reserved_size());
> 198:     }

Again Why is this unconditional? I expected it to be in `#ifdef LEAK_SANITIZER`

src/hotspot/share/runtime/java.cpp line 432:

> 430:     static_cast<void>(result);
> 431:   }
> 432: 

Why is this unconditional? I expected it to be in `#ifdef LEAK_SANITIZER`

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

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


From dholmes at openjdk.org  Thu Feb  2 06:13:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Feb 2023 06:13:30 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <ka7iNEhBDJZ28wEcaAnfiNqCoJV2vmkyOz7O0xR1YCs=.5b5e81a5-d77e-41e3-b16e-a97331238b17@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
 <ka7iNEhBDJZ28wEcaAnfiNqCoJV2vmkyOz7O0xR1YCs=.5b5e81a5-d77e-41e3-b16e-a97331238b17@github.com>
Message-ID: <6xcgr1n9j4B5--0YAAqKybMi2Rd4W_OOv0nvQwDWhcY=.b99607ae-d25a-4429-bc73-27ccf5a82ede@github.com>

On Thu, 2 Feb 2023 06:01:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Support CDS
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> src/hotspot/share/runtime/arguments.cpp line 3979:
> 
>> 3977:   // LSAN relies on pointers to be natively aligned. Using compressed class pointers breaks this
>> 3978:   // expectation and results in nondeterministic leak reports.
>> 3979:   if (FLAG_SET_CMDLINE(UseCompressedOops, false) != JVMFlag::SUCCESS) {
> 
> This positioning doesn't look right. There are a number of inter-dependencies on the compressed oops flags and I don't think you can just turn them off here. Surely `Arguments::set_use_compressed_oops()` is where this needs to be done?

Not sure FLAG_SET_CMDLINE is right here either (but flag setting is very confusing).

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

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


From stuefe at openjdk.org  Thu Feb  2 06:24:24 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 2 Feb 2023 06:24:24 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
Message-ID: <Ck13vTqYdE1Y34xb6oCXzUsDwaCWD8CunHOqN0sxRXs=.b3c4c8f3-0dbe-4b3e-9337-21ec0fd4c66c@github.com>

On Wed, 1 Feb 2023 15:26:27 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that rely on testing compressed oops or compressed class pointers. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - `UseCompressedOops` and `UseCompressedClassPointers` are forced to false when LSan is enabled. This is necessary to ensure all pointers to memory which could possible container pointers to malloc memory are property aligned, which is an LSan requirement.
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. This is due to the other caveats. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>> - There are a series of tests that are upset due to the above flags being forced false, as they rely on the arguments being supported. In the future ideally these tests would be skipped nicely when LSan is enabled.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support CDS
>   
>   Signed-off-by: Justin King <jcking at google.com>

I think this is very useful, but the reliance on -UseCompressedOops and -UseCompressedClassPointers is unfortunate. Especially the latter. With Project Liliput, we plan to eliminate uncompressed class pointers altogether (there is really no good reason to not have them even in today's JVM unless you plan to load more than ~4million classes).

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

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


From stuefe at openjdk.org  Thu Feb  2 06:37:23 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 2 Feb 2023 06:37:23 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
Message-ID: <9Q5Yb8KEUtCRCVYWSAD0WxGEfOCxAmov9_g1zQ8i7fM=.fa6eb056-13b9-4057-9adf-c5d185f4895b@github.com>

On Wed, 1 Feb 2023 15:26:27 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that rely on testing compressed oops or compressed class pointers. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - `UseCompressedOops` and `UseCompressedClassPointers` are forced to false when LSan is enabled. This is necessary to ensure all pointers to memory which could possible container pointers to malloc memory are property aligned, which is an LSan requirement.
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. This is due to the other caveats. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>> - There are a series of tests that are upset due to the above flags being forced false, as they rely on the arguments being supported. In the future ideally these tests would be skipped nicely when LSan is enabled.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Support CDS
>   
>   Signed-off-by: Justin King <jcking at google.com>

Thinking this through some more:

Why would UseCompressedClassPointers cause leak analysis to fail? Because you track Metaspace? If so, we should think whether it makes sense to track Metaspace.

Metaspace memory is tied to class loaders. Class loaders may live forever, until VM death, in that case Metaspace will not be released. How exactly does the leak profiler deal with that? Does it report those cases as leaks?

Metaspace "leaks" exist, but these are typically class loader leaks at the application level, and those you cannot recognize from the JVM. You need application knowledge for that.

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

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


From jcking at openjdk.org  Thu Feb  2 15:52:01 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 2 Feb 2023 15:52:01 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v3]
In-Reply-To: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
Message-ID: <pyIAB3MYuJUbHYZGYObPZGfYO8C_lrGVAqP_I_Tz6k0=.2ca7885e-3be7-4933-bd8a-515c793de6a0@github.com>

> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that rely on testing compressed oops or compressed class pointers. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
> 
> **Suppressing:**
> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
> 
> **Caveats:**
> - `UseCompressedOops` and `UseCompressedClassPointers` are forced to false when LSan is enabled. This is necessary to ensure all pointers to memory which could possible container pointers to malloc memory are property aligned, which is an LSan requirement.
> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. This is due to the other caveats. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
> - There are a series of tests that are upset due to the above flags being forced false, as they rely on the arguments being supported. In the future ideally these tests would be skipped nicely when LSan is enabled.

Justin King has updated the pull request incrementally with two additional commits since the last revision:

 - Fix grammatical error
   
   Signed-off-by: Justin King <jcking at google.com>
 - Update based on review and remove restriction on compressed oops and class pointers
   
   Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12229/files
  - new: https://git.openjdk.org/jdk/pull/12229/files/4559ef4c..93af227a

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

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

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


From jcking at openjdk.org  Thu Feb  2 15:52:10 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 2 Feb 2023 15:52:10 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <ka7iNEhBDJZ28wEcaAnfiNqCoJV2vmkyOz7O0xR1YCs=.5b5e81a5-d77e-41e3-b16e-a97331238b17@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
 <ka7iNEhBDJZ28wEcaAnfiNqCoJV2vmkyOz7O0xR1YCs=.5b5e81a5-d77e-41e3-b16e-a97331238b17@github.com>
Message-ID: <9Ssbs9Bn5_RKgHETiinaboR6Jca2RuQKCjAiA74XZu0=.57bcfad8-45df-4866-bc38-6ea8beffb8c7@github.com>

On Thu, 2 Feb 2023 05:34:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Support CDS
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> make/data/lsan/lsan_default_options.c line 49:
> 
>> 47: // extremely early during library loading, before main is called.  We need to override the default
>> 48: // options because LSan will perform leak checking at program exit. Unfortunately Hotspot does not
>> 49: // shutdown cleaning at the moment and some leaks occur, we want to ignore these. Instead we
> 
> s/cleaning/cleanly/

Fixed.

> src/hotspot/share/runtime/init.cpp line 198:
> 
>> 196:       VirtualSpaceSummary summary = Universe::heap()->create_heap_space_summary();
>> 197:       LSAN_UNREGISTER_ROOT_REGION(summary.start(), summary.reserved_size());
>> 198:     }
> 
> Again Why is this unconditional? I expected it to be in `#ifdef LEAK_SANITIZER`

Same as other comment. This does more than just the LSAN_*, so I wrapped it now.

> src/hotspot/share/runtime/java.cpp line 432:
> 
>> 430:     static_cast<void>(result);
>> 431:   }
>> 432: 
> 
> Why is this unconditional? I expected it to be in `#ifdef LEAK_SANITIZER`

Since this does a little more than just invoke the LSAN_* macros, that is fair. I wrapped it in an ifdef.

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

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


From jcking at openjdk.org  Thu Feb  2 15:52:11 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 2 Feb 2023 15:52:11 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <6xcgr1n9j4B5--0YAAqKybMi2Rd4W_OOv0nvQwDWhcY=.b99607ae-d25a-4429-bc73-27ccf5a82ede@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
 <ka7iNEhBDJZ28wEcaAnfiNqCoJV2vmkyOz7O0xR1YCs=.5b5e81a5-d77e-41e3-b16e-a97331238b17@github.com>
 <6xcgr1n9j4B5--0YAAqKybMi2Rd4W_OOv0nvQwDWhcY=.b99607ae-d25a-4429-bc73-27ccf5a82ede@github.com>
Message-ID: <WFnRHQQTRoMmIT8C-Dfwg_IHgDFZvz-wssH2e88biBg=.a007a12e-369c-40b9-893d-4a1110e02b22@github.com>

On Thu, 2 Feb 2023 06:06:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/arguments.cpp line 3979:
>> 
>>> 3977:   // LSAN relies on pointers to be natively aligned. Using compressed class pointers breaks this
>>> 3978:   // expectation and results in nondeterministic leak reports.
>>> 3979:   if (FLAG_SET_CMDLINE(UseCompressedOops, false) != JVMFlag::SUCCESS) {
>> 
>> This positioning doesn't look right. There are a number of inter-dependencies on the compressed oops flags and I don't think you can just turn them off here. Surely `Arguments::set_use_compressed_oops()` is where this needs to be done?
>
> Not sure FLAG_SET_CMDLINE is right here either (but flag setting is very confusing).

Removed, no longer needed. I'll explain below.

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

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


From jcking at openjdk.org  Thu Feb  2 16:05:43 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 2 Feb 2023 16:05:43 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <9Q5Yb8KEUtCRCVYWSAD0WxGEfOCxAmov9_g1zQ8i7fM=.fa6eb056-13b9-4057-9adf-c5d185f4895b@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
 <9Q5Yb8KEUtCRCVYWSAD0WxGEfOCxAmov9_g1zQ8i7fM=.fa6eb056-13b9-4057-9adf-c5d185f4895b@github.com>
Message-ID: <Y8rxc8RJ_qO0LWmx11XvIuhHFvy9iNCpCXx_FdqmuYc=.929a3bd8-5332-4944-9fdf-aff68302badd@github.com>

On Thu, 2 Feb 2023 06:34:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Support CDS
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> Thinking this through some more:
> 
> Why would UseCompressedClassPointers cause leak analysis to fail? Because you track Metaspace? If so, we should think whether it makes sense to track Metaspace.
> 
> Metaspace memory is tied to class loaders. Class loaders may live forever, until VM death, in that case Metaspace will not be released. How exactly does the leak profiler deal with that? Does it report those cases as leaks?
> 
> Metaspace "leaks" exist, but these are typically class loader leaks at the application level, and those you cannot recognize from the JVM. You need application knowledge for that.

@tstuefe 

Okay, I removed the forceful disabling of `UseCompressedOops` and `UseCompressedClassPointers` and it looks clean, so I removed that. I think what happened was two things. First, when I started this many months ago I did not have a full understanding of the different memory regions used by Hotspot compared to now and second when I was originally doing this I got false positive feedback by disabling these likely due to missing registration of a root region. So I originally chalked it up to being due to misaligned pointers. My original goal was to just get a clean run, so I took the hammer approach.

As long as the pointers to malloc-based memory are properly aligned in one of the root regions (ones we register or other memory allocated by malloc), LSan is happy. It shouldn't matter whether pointers to data in metaspace are compressed or not, or oops. Both reside in metaspace and java heap, neither of which LSan is directly concerned about other than looking for pointers to malloc-based memory. So you are correct in that regard that neither `UseCompressedOops` and `UseCompressedClassPointers` should be necessary. However metaspace leaks do exist and this setup actually found one (JDK-8298084), so metaspace being instrumented is definitely useful.

To clarify, LSan is only concerned with leaks related to memory obtained from malloc and friends. It does not deal with metaspace leaks directly or java heap leaks.

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

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


From erikj at openjdk.org  Thu Feb  2 22:52:00 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 2 Feb 2023 22:52:00 GMT
Subject: RFR: 8301717: Remove obsolete jib profiles
Message-ID: <i0JMNwIGtf8qJQKmF4nqcFymwB0VbowdePt3zRKiQow=.03dfde57-c188-4f6d-92dd-aa78d9a0cb32@github.com>

This patch removes some now obsolete jib profiles configurations.

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

Commit messages:
 - JDK-8301717

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

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


From dholmes at openjdk.org  Fri Feb  3 04:21:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Feb 2023 04:21:49 GMT
Subject: RFR: 8301717: Remove obsolete jib profiles
In-Reply-To: <i0JMNwIGtf8qJQKmF4nqcFymwB0VbowdePt3zRKiQow=.03dfde57-c188-4f6d-92dd-aa78d9a0cb32@github.com>
References: <i0JMNwIGtf8qJQKmF4nqcFymwB0VbowdePt3zRKiQow=.03dfde57-c188-4f6d-92dd-aa78d9a0cb32@github.com>
Message-ID: <JJCA3iW14GNDooHxvSxwIEFLULBr8m7tmuLv59GVX4I=.a949d780-e910-4fc7-a288-cee3c5d6b343@github.com>

On Thu, 2 Feb 2023 22:44:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch removes some now obsolete jib profiles configurations.

Removal seems fine. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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


From dholmes at openjdk.org  Fri Feb  3 04:29:53 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Feb 2023 04:29:53 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v3]
In-Reply-To: <pyIAB3MYuJUbHYZGYObPZGfYO8C_lrGVAqP_I_Tz6k0=.2ca7885e-3be7-4933-bd8a-515c793de6a0@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <pyIAB3MYuJUbHYZGYObPZGfYO8C_lrGVAqP_I_Tz6k0=.2ca7885e-3be7-4933-bd8a-515c793de6a0@github.com>
Message-ID: <z9eLdHXw2HTpLaga4e_Ol-cxsn_zfT2z000ictzX0iU=.2fcc5357-d6b2-4bff-832f-4972b730c858@github.com>

On Thu, 2 Feb 2023 15:52:01 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>
> Justin King has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix grammatical error
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Update based on review and remove restriction on compressed oops and class pointers
>    
>    Signed-off-by: Justin King <jcking at google.com>

Updates look good - glad to see the flag changes go away!

I suggest factoring out the change to `test/jdk/jni/nullCaller/exeNullCallerTest.cpp` as it is a JDK test and not part of hotspot. Thanks.

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

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


From stuefe at openjdk.org  Fri Feb  3 06:18:51 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 3 Feb 2023 06:18:51 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <9Q5Yb8KEUtCRCVYWSAD0WxGEfOCxAmov9_g1zQ8i7fM=.fa6eb056-13b9-4057-9adf-c5d185f4895b@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
 <9Q5Yb8KEUtCRCVYWSAD0WxGEfOCxAmov9_g1zQ8i7fM=.fa6eb056-13b9-4057-9adf-c5d185f4895b@github.com>
Message-ID: <vDAsC50DIWRCI7JzHUAFncoDcdK0x5-4MBg8hIrPUKs=.b6417dbf-390a-4118-aded-b193a8feb2de@github.com>

On Thu, 2 Feb 2023 06:34:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Support CDS
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> Thinking this through some more:
> 
> Why would UseCompressedClassPointers cause leak analysis to fail? Because you track Metaspace? If so, we should think whether it makes sense to track Metaspace.
> 
> Metaspace memory is tied to class loaders. Class loaders may live forever, until VM death, in that case Metaspace will not be released. How exactly does the leak profiler deal with that? Does it report those cases as leaks?
> 
> Metaspace "leaks" exist, but these are typically class loader leaks at the application level, and those you cannot recognize from the JVM. You need application knowledge for that.

> @tstuefe
> 
> Okay, I removed the forceful disabling of `UseCompressedOops` and `UseCompressedClassPointers` and it looks clean, so I removed that. I think what happened was two things. First, when I started this many months ago I did not have a full understanding of the different memory regions used by Hotspot compared to now and second when I was originally doing this I got false positive feedback by disabling these likely due to missing registration of a root region. So I originally chalked it up to being due to misaligned pointers. My original goal was to just get a clean run, so I took the hammer approach.
> 
> As long as the pointers to malloc-based memory are properly aligned in one of the root regions (ones we register or other memory allocated by malloc), LSan is happy. It shouldn't matter whether pointers to data in metaspace are compressed or not, or oops. Both reside in metaspace and java heap, neither of which LSan is directly concerned about other than looking for pointers to malloc-based memory. So you are correct in that regard that neither `UseCompressedOops` and `UseCompressedClassPointers` should be necessary. However metaspace leaks do exist and this setup actually found one (JDK-8298084), so metaspace being instrumented is definitely useful.

Thanks for the explanation. Do I understand correctly: You register address ranges with LSAN, and at certain points (program exit?) the memory is examined for pointers that point still to unreleased memory? Does LSAN instrument malloc and free?

> 
> To clarify, LSan is only concerned with leaks related to memory obtained from malloc and friends. It does not deal with metaspace leaks directly or java heap leaks.

Metaspace objects hold pointers to malloced memory. Metaspace Objects can leak, that's accepted. So these pointers would leak too. Would that not give us tons of false positives?

In other words, in Metaspace, we need to distinguish real malloc pointer leaks from allowed ones, otherwise monitoring Metaspace is not useful. Real leaks would be malloc pointers in metaspace objects that had been implicitly released by metaspace arena death.

I need to think more about this some more. Tracking leaks from metaspace objects could be useful. We could always postpone tracking Metaspace malloc pointers to another RFE, in which case I would remove the changes to VirtualSpaceNode.

@dholmes-ora : Do all the sub-data tied to metaspace objects really have to live in C-heap? They mostly do have the same lifetime as the parent object. It would be logical for them to live in Metaspace too - no need to explicitly release them in the various release_C_heap_structures. Cheaper too, since malloc is comparatively expensive.

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

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


From dholmes at openjdk.org  Fri Feb  3 08:34:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 3 Feb 2023 08:34:52 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v3]
In-Reply-To: <z9eLdHXw2HTpLaga4e_Ol-cxsn_zfT2z000ictzX0iU=.2fcc5357-d6b2-4bff-832f-4972b730c858@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <pyIAB3MYuJUbHYZGYObPZGfYO8C_lrGVAqP_I_Tz6k0=.2ca7885e-3be7-4933-bd8a-515c793de6a0@github.com>
 <z9eLdHXw2HTpLaga4e_Ol-cxsn_zfT2z000ictzX0iU=.2fcc5357-d6b2-4bff-832f-4972b730c858@github.com>
Message-ID: <C4-cgmJSxq7rI74ofzJG4RiaKXfJb2f3coGDPMcg09Y=.7ef57fb9-6d5a-414e-aa70-6f4d0fc8a6c2@github.com>

On Fri, 3 Feb 2023 04:26:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix grammatical error
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>>  - Update based on review and remove restriction on compressed oops and class pointers
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>
> Updates look good - glad to see the flag changes go away!
> 
> I suggest factoring out the change to `test/jdk/jni/nullCaller/exeNullCallerTest.cpp` as it is a JDK test and not part of hotspot. Thanks.

> @dholmes-ora : Do all the sub-data tied to metaspace objects really have to live in C-heap?

@tstuefe  - sorry I have no knowledge about that. Perhaps @coleenp can answer?

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

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


From asotona at openjdk.org  Fri Feb  3 14:31:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 3 Feb 2023 14:31:24 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Classfile API moved under jdk.internal.classfile package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/80213e61..8df1dc21

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

  Stats: 21514 lines in 401 files changed: 10054 ins; 10054 del; 1406 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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


From jcking at openjdk.org  Fri Feb  3 15:11:52 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 3 Feb 2023 15:11:52 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]
In-Reply-To: <vDAsC50DIWRCI7JzHUAFncoDcdK0x5-4MBg8hIrPUKs=.b6417dbf-390a-4118-aded-b193a8feb2de@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <b-for6GZTZFuu5w58IBPMAndYi6hvrXT5xysLRVpfOE=.0870666e-f310-4745-a99c-7ed587d5a720@github.com>
 <9Q5Yb8KEUtCRCVYWSAD0WxGEfOCxAmov9_g1zQ8i7fM=.fa6eb056-13b9-4057-9adf-c5d185f4895b@github.com>
 <vDAsC50DIWRCI7JzHUAFncoDcdK0x5-4MBg8hIrPUKs=.b6417dbf-390a-4118-aded-b193a8feb2de@github.com>
Message-ID: <_NnlbvduQz7iO5RIVJtALHW_ZmksdiH9XWgpz94s4_A=.54301297-1c6c-4722-9aee-348dbb0957db@github.com>

On Fri, 3 Feb 2023 06:16:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Thanks for the explanation. Do I understand correctly: You register address ranges with LSAN, and at certain points (program exit?) the memory is examined for pointers that point still to unreleased memory? Does LSAN instrument malloc and free?

LSan intercepts all malloc-related functions and is its own allocator. It normally performs leak checking at program exit, but we disable this behavior. We do not particularly care about leaks that happen as a result of the shutdown process. Instead we trigger leak checking extremely early in the JVM shutdown process, immediately after the synchronization lock but before the shutdown logic actually occurs. When LSan performs leak checking, the entire process is paused except the thread performing the leak checking. LSan is aware of all memory that has been allocated up until that point, let's call it set `A`, its goal is to prove that all pointers (the ones returned by malloc and friends) are present. It considers other memory allocated by malloc, the mutable data section of the executable, our registered root regions, and some others. During scanning if it finds the pointer to an allocation in set `A`, besides from an allocation itself, it marks it. It must be the pointer returned b
 y malloc and friends itself, not a pointer to a subregion of the allocation. After the scanning process, leaks are all the allocations in set `A` that have not been marked.

> Metaspace objects hold pointers to malloced memory. Metaspace Objects can leak, that's accepted. So these pointers would leak too. Would that not give us tons of false positives?

No. LSan only cares that it can find pointers to malloc'ed memory, not that it can find pointers to Metaspace objects. The Metaspace is registered as a root region. It does however take into account ASan poisoning, which we added earlier to Metaspace. LSan will not scan poisoned memory regions that are part of root regions. We only poison in Metaspace when deallocation occurs and unpoison when allocation occurs.

So there are no false positives there.

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

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


From mcimadamore at openjdk.org  Fri Feb  3 18:42:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 3 Feb 2023 18:42:12 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
Message-ID: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>

On Fri, 3 Feb 2023 14:31:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Classfile API moved under jdk.internal.classfile package

src/java.base/share/classes/jdk/internal/classfile/AttributedElement.java line 94:

> 92:      * are permitted.
> 93:      */
> 94:     enum Kind {

Not sure how to interpret this. This seems to refer to an attribute - e.g. where is an attribute allowed - rather than to the element (e.g. the declaration to which the attribute is attached). All the constants are unused, so hard to make sense of how this is used.

src/java.base/share/classes/jdk/internal/classfile/Attributes.java line 774:

> 772:      */
> 773:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
> 774:         int hash = name.hashCode();

If we have a map, why do we need this "inlined" map here? Performance reasons?

src/java.base/share/classes/jdk/internal/classfile/BootstrapMethodEntry.java line 41:

> 39:  * part of the constant pool.
> 40:  */
> 41: public sealed interface BootstrapMethodEntry

Usages of this seem all to fall into the `constantpool` package - does this interface belong there?

src/java.base/share/classes/jdk/internal/classfile/BufWriter.java line 40:

> 38:  * to the end of the buffer, as well as to create constant pool entries.
> 39:  */
> 40: public sealed interface BufWriter

What is the relationship between this and ClassReader? Is one the dual of the other - e.g. is the intended use for BufWriter to write custom attributes, whereas ClassReader reads custom attributes?

src/java.base/share/classes/jdk/internal/classfile/ClassModel.java line 104:

> 102:      * found
> 103:      */
> 104:     default List<VerifyError> verify(Consumer<String> debugOutput) {

not super sure whether `verify` belongs here - could be another component in the `components` package?

src/java.base/share/classes/jdk/internal/classfile/ClassSignature.java line 34:

> 32:  * Models the generic signature of a class file, as defined by JVMS 4.7.9.
> 33:  */
> 34: public sealed interface ClassSignature

It is a bit odd to have Signature and XYZSignature in the API with the latter not extending the former. I think I get what the API is aiming for though - e.g. Signature is for modelling low-level "portions" of the signature attributes, whereas ClassSignature, MethodSignature and friends are there to model the signature attribute attached to a class, method, etc.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 58:

> 56:  * Main entry points for parsing, transforming, and generating classfiles.
> 57:  */
> 58: public class Classfile {

class or interface? (bikeshed, I realize)

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 197:

> 195:      * @return the classfile bytes
> 196:      */
> 197:     public static byte[] build(ClassDesc thisClass,

The "build" methods here seem regular - e.g. build { class, module } x { byte array, path }. As a future improvement, perhaps capturing the "sink" of a build process might be helpful - so that you can avoid overloads between array and path variants. (e.g. `build(.... toByteArray(arr))`, or `build(...).toByteArray(...)`.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 346:

> 344:     public static final int MAGIC_NUMBER = 0xCAFEBABE;
> 345: 
> 346:     public static final int NOP             = 0;

Not sure how I feel about the constants being here. It seems to me that they can be moved to more appropriate places - e.g. Instructor, TypeAnnotation (for the TAT ones), ConstantPool (for the TAG ones).

The classfile versions, OTOH, do seem to belong here.

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 202:

> 200:     default CodeBuilder block(Consumer<BlockCodeBuilder> handler) {
> 201:         Label breakLabel = newLabel();
> 202:         BlockCodeBuilderImpl child = new BlockCodeBuilderImpl(this, breakLabel);

Nice trick! I like the `breakLabel` concept

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 333:

> 331:          * @see #catchingAll
> 332:          */
> 333:         CatchBuilder catching(ClassDesc exceptionType, Consumer<BlockCodeBuilder> catchHandler);

I imagine there are name clashes with Java keyword, hence the `ing` in the names. That said, this should probably revisited in a later bikeshedding round - as in the current form, the code builder API has most method names that are nouns (the thing being built) but it also has some verbs in there (trying, catching) which seem odd.

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 613:

> 611:     }
> 612: 
> 613:     default CodeBuilder labelBinding(Label label) {

Maybe just `bind` or `bindLabel` ?

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1371:

> 1369:     }
> 1370: 
> 1371:     default CodeBuilder tableswitch(Label defaultTarget, List<SwitchCase> cases) {

`switch` seems the one instruction for which an high-level variant (like `trying`) could be useful, as generating code for that can be quite painful.

src/java.base/share/classes/jdk/internal/classfile/FieldTransform.java line 92:

> 90:      * @return the field transform
> 91:      */
> 92:     static FieldTransform dropping(Predicate<FieldElement> filter) {

Could this be a more general static generic method on ClassfileTransform? (but I see CodeTransform doesn't have it - not sure if that's deliberate).

src/java.base/share/classes/jdk/internal/classfile/Opcode.java line 39:

> 37:  */
> 38: public enum Opcode {
> 39:     NOP(Classfile.NOP, 1, Kind.NOP),

This also duplicates the constants in classfile...

src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 75:

> 73:      * The kind of target on which the annotation appears.
> 74:      */
> 75:     public enum TargetType {

My IDE says this enum is not being used. I tend to believe it, since the TargetInfo sealed interface also seems to model the same thing?

src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 577:

> 575: 
> 576:     /**
> 577:      * type_path.path.

The javadoc in this class seems off

src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 617:

> 615:         }
> 616: 
> 617:         public static final TypePathComponent ARRAY = new UnboundAttribute.TypePathComponentImpl(Kind.ARRAY, 0);

`public static final` is redundant here (it's an interface) - please check these (I've seen others). E.g. all `public` modifier for types nested in interfaces are redundant as well.

src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 641:

> 639:         int typeArgumentIndex();
> 640: 
> 641:         static TypePathComponent of(int typePathKind, int typeArgumentIndex) {

Should this take a `Kind` instead of an `int`?

src/java.base/share/classes/jdk/internal/classfile/attribute/SignatureAttribute.java line 66:

> 64: 
> 65:     /**
> 66:      * Parse the siganture as a method signature.

typo here `siganture` - check the entire class

src/java.base/share/classes/jdk/internal/classfile/package-info.java line 39:

> 37:  * <p>
> 38:  * {@snippet lang=java :
> 39:  * ClassModel cm = ClassModel.of(bytes);

There are several references to `ClassModel::of` (here and elsewhere), but this seems to have been moved to `ClassFile::parse`

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

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


From mcimadamore at openjdk.org  Fri Feb  3 18:42:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 3 Feb 2023 18:42:15 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <2dfIIfnZwgc-wezRVH81l9b5VjLjP02k7PjU64wjAww=.5c9e7ba6-4254-46cd-a6c0-553dcea7dc3b@github.com>

On Fri, 3 Feb 2023 17:46:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 346:
> 
>> 344:     public static final int MAGIC_NUMBER = 0xCAFEBABE;
>> 345: 
>> 346:     public static final int NOP             = 0;
> 
> Not sure how I feel about the constants being here. It seems to me that they can be moved to more appropriate places - e.g. Instructor, TypeAnnotation (for the TAT ones), ConstantPool (for the TAG ones).
> 
> The classfile versions, OTOH, do seem to belong here.

Actually, we also have a ClassfileVersion class, so that could be a better place for version numbers?

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

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


From ysuenaga at openjdk.org  Sat Feb  4 09:49:28 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 4 Feb 2023 09:49:28 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
Message-ID: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>

C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.

* HotSpot
    * stubGenerator_x86_64_poly.cpp
    * elfFile.hpp
* libfontmanager
    * hb.hh
* libfreetype
    * afblue.c

I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

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

Commit messages:
 - 8301820: C4819 warnings were reported on Windows

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

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


From mikael at openjdk.org  Sat Feb  4 23:11:48 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Sat, 4 Feb 2023 23:11:48 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
Message-ID: <Mn7sVCW4DX14Y-gt8vuRpxA-5oxfkdQYbjJIf6DkKLQ=.dadf5238-6d61-44e6-a85e-e4d923cb48c8@github.com>

On Sat, 4 Feb 2023 09:42:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
> 
> * HotSpot
>     * stubGenerator_x86_64_poly.cpp
>     * elfFile.hpp
> * libfontmanager
>     * hb.hh
> * libfreetype
>     * afblue.c
> 
> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

Out of curiosity, which version of VS 2022 is this?

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

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


From ysuenaga at openjdk.org  Sun Feb  5 00:42:52 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 5 Feb 2023 00:42:52 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
Message-ID: <3QCTFOqlvgfDS3Q4ZTGt75I4ot6DQKQQ7XBEItYkKKY=.d5778a31-13dc-4499-9b9b-fc64ed071bb6@github.com>

On Sat, 4 Feb 2023 09:42:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
> 
> * HotSpot
>     * stubGenerator_x86_64_poly.cpp
>     * elfFile.hpp
> * libfontmanager
>     * hb.hh
> * libfreetype
>     * afblue.c
> 
> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

I uses 17.3.6 (VS Community) on Windows 11 Pro (Japanese locale (CP932))

I saw following message on the console (It is Japanese, sorry...)


d:\github-forked\jdk\src\hotspot\cpu\x86\stubGenerator_x86_64_poly.cpp(1): error C2220: ?????????????????
d:\github-forked\jdk\src\hotspot\cpu\x86\stubGenerator_x86_64_poly.cpp(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????


In case of stubGenerator_x86_64_poly.cpp , `?` in comments cannot be handled in cl.exe. I confirmed that this character cannot be handled `iconv -f CP932 -t UTF8`, so I replaced it to `x` (alphabet).

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

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


From dholmes at openjdk.org  Mon Feb  6 01:08:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Feb 2023 01:08:49 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
Message-ID: <w77y3xj7j9OXjIFUH86lSFz0Je8R79FMoY6wAvE9PRw=.b2c037c8-f6c3-472b-977c-ad55ceeb5939@github.com>

On Sat, 4 Feb 2023 09:42:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
> 
> * HotSpot
>     * stubGenerator_x86_64_poly.cpp
>     * elfFile.hpp
> * libfontmanager
>     * hb.hh
> * libfreetype
>     * afblue.c
> 
> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

Sorry Yasumasa, but I'd much prefer to see this split into three sub-tasks (or issues) just so we can keep the issues more clearly separated.

IIUC for stubGenerator_x86_64_poly.cpp we have a multiplication symbol instead of an ascii 'x' (likely pasted from a word processing document).

For elfFile.hpp there are smart-quotes instead of ascii "

Thanks.

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

Changes requested by dholmes (Reviewer).

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


From jpai at openjdk.org  Mon Feb  6 07:03:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 Feb 2023 07:03:25 GMT
Subject: RFR: 8301834: Templated Buffer classes leave a lot of empty lines in
 the generated source
Message-ID: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>

Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?

Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:

>  If -nel is declared then empty lines will not be substituted for lines of
>  text in the template that do not appear in the output.

Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.

Existing tests in `test/jdk/java/nio` continue to pass after this change. I've always checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.

Additional `tier` testing has been triggered to make sure no regression is introduced.

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

Commit messages:
 - 8301834: Templated Buffer classes leave a lot of empty lines in the generated source

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

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


From haosun at openjdk.org  Mon Feb  6 07:09:15 2023
From: haosun at openjdk.org (Hao Sun)
Date: Mon, 6 Feb 2023 07:09:15 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <-RReNBa4rbWMG38xuIH_yCfzDDEubd4gU2QsVCdiubM=.0e13582c-f1c8-4e35-a1ce-174a22b86a58@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
 <-RReNBa4rbWMG38xuIH_yCfzDDEubd4gU2QsVCdiubM=.0e13582c-f1c8-4e35-a1ce-174a22b86a58@github.com>
Message-ID: <4v4pdOt2xrFJx30NbLByS6jw3p_y3NSutAxIQq_I-lg=.cedfdf56-6a23-46b6-8cd3-044a467c2c61@github.com>

On Tue, 31 Jan 2023 14:59:31 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Alan Hayward has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge master
>>  - Merge master
>>  - Merge master
>>  - Error on -XX:-PreserveFramePointer -XX:UseBranchProtection=pac-ret
>>  - Add comments to enter calls
>>  - Set PreserveFramePointer if use_rop_protection is set
>>  - Merge enter_subframe into enter
>>  - Review fixups
>>  - Documentation updates
>>  - Update copyrights to 2022
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/022d8070...c4e0ee31
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 413:
> 
>> 411:   }
>> 412: 
>> 413:   if (UseBranchProtection == nullptr || strcmp(UseBranchProtection, "none") == 0) {
> 
> My understanding is that `UseBranchProtection` requires JIT compiler integration. This is currently missing in Graal. The logic that decides if it should be enabled by default needs to take JVMCI into consideration, much like the call to `JVMCIGlobals::check_jvmci_supported_gc` determines if JVMCI supports the configured GC.
> 
> Thanks to @gilles-duboscq for alerting me to this change.

Thanks for reporting this. @dougxc 

Yes. I encountered several jtreg failures with Graal, which is built with PAC-RET enabled JDK.

As I see it, the straightforward fix is to disable JVMCI if `_rop_protection` is parsed as "true" finally, since Graal doesn't supports PAC-RET currently. 
That is similar to the way `JVMCIGlobals::check_jvmci_supported_gc` does, i.e. if one GC except `G1/Serial/Parallel` is configured, we disable JVMCI.
WDYT

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

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


From alanb at openjdk.org  Mon Feb  6 08:05:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Feb 2023 08:05:50 GMT
Subject: RFR: 8301834: Templated Buffer classes leave a lot of empty lines
 in the generated source
In-Reply-To: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
References: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
Message-ID: <EPHXKsBRiK7YneI_e6PQeMArUNYw_S4FLgwpDfKu7oU=.979d972b-30f3-4ba6-ab24-ee19f9d3ba4f@github.com>

On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?
> 
> Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:
> 
>>  If -nel is declared then empty lines will not be substituted for lines of
>>  text in the template that do not appear in the output.
> 
> Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.
> 
> Existing tests in `test/jdk/java/nio` continue to pass after this change. I've checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.
> 
> Additional `tier` testing has been triggered to make sure no regression is introduced.

See JDK-8207804 for the last discussion on this issue.

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

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


From jpai at openjdk.org  Mon Feb  6 08:59:00 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 Feb 2023 08:59:00 GMT
Subject: RFR: 8301834: Templated Buffer classes leave a lot of empty lines
 in the generated source
In-Reply-To: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
References: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
Message-ID: <065Y_wY9PnpHKTQqlBdg4pzfhGf1kYyjpkIatxYPuYA=.85fb4dfc-8005-4b30-a087-788a6a9841b2@github.com>

On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?
> 
> Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:
> 
>>  If -nel is declared then empty lines will not be substituted for lines of
>>  text in the template that do not appear in the output.
> 
> Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.
> 
> Existing tests in `test/jdk/java/nio` continue to pass after this change. I've checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.
> 
> Additional `tier` testing has been triggered to make sure no regression is introduced.

Thank you Alan for pointing to the previous discussion.

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

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


From jpai at openjdk.org  Mon Feb  6 08:59:01 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 Feb 2023 08:59:01 GMT
Subject: Withdrawn: 8301834: Templated Buffer classes leave a lot of empty
 lines in the generated source
In-Reply-To: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
References: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
Message-ID: <CdY6C4XLttS82FmapCWhw-ddEp8jyLdT6ofY-84_1GY=.994c8fb3-826f-4f7b-a427-0c2fe980b729@github.com>

On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?
> 
> Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:
> 
>>  If -nel is declared then empty lines will not be substituted for lines of
>>  text in the template that do not appear in the output.
> 
> Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.
> 
> Existing tests in `test/jdk/java/nio` continue to pass after this change. I've checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.
> 
> Additional `tier` testing has been triggered to make sure no regression is introduced.

This pull request has been closed without being integrated.

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

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


From dnsimon at openjdk.org  Mon Feb  6 11:54:18 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 6 Feb 2023 11:54:18 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <4v4pdOt2xrFJx30NbLByS6jw3p_y3NSutAxIQq_I-lg=.cedfdf56-6a23-46b6-8cd3-044a467c2c61@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
 <-RReNBa4rbWMG38xuIH_yCfzDDEubd4gU2QsVCdiubM=.0e13582c-f1c8-4e35-a1ce-174a22b86a58@github.com>
 <4v4pdOt2xrFJx30NbLByS6jw3p_y3NSutAxIQq_I-lg=.cedfdf56-6a23-46b6-8cd3-044a467c2c61@github.com>
Message-ID: <VFi-Q8AqSpe1D0Go6eIFEfE8okl9Z6V95rNL4AAH8Ag=.e0f4ce27-e49d-450e-83ef-b2d2d4bd60d4@github.com>

On Mon, 6 Feb 2023 07:05:39 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 413:
>> 
>>> 411:   }
>>> 412: 
>>> 413:   if (UseBranchProtection == nullptr || strcmp(UseBranchProtection, "none") == 0) {
>> 
>> My understanding is that `UseBranchProtection` requires JIT compiler integration. This is currently missing in Graal. The logic that decides if it should be enabled by default needs to take JVMCI into consideration, much like the call to `JVMCIGlobals::check_jvmci_supported_gc` determines if JVMCI supports the configured GC.
>> 
>> Thanks to @gilles-duboscq for alerting me to this change.
>
> Thanks for reporting this. @dougxc 
> 
> Yes. I encountered several jtreg failures with Graal, which is built with PAC-RET enabled JDK.
> 
> As I see it, the straightforward fix is to disable JVMCI if `_rop_protection` is parsed as "true" finally, since Graal doesn't supports PAC-RET currently. 
> That is similar to the way `JVMCIGlobals::check_jvmci_supported_gc` does, i.e. if one GC except `G1/Serial/Parallel` is configured, we disable JVMCI.
> WDYT

The problem with `JVMCIGlobals::check_jvmci_supported_gc` is that it does not give the compiler a chance to specify whether it supports a given GC.
Instead, we want a JVMCI upcall like `jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.isGCSupported(int)`.

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

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


From ysuenaga at openjdk.org  Mon Feb  6 12:40:04 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 6 Feb 2023 12:40:04 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <w77y3xj7j9OXjIFUH86lSFz0Je8R79FMoY6wAvE9PRw=.b2c037c8-f6c3-472b-977c-ad55ceeb5939@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
 <w77y3xj7j9OXjIFUH86lSFz0Je8R79FMoY6wAvE9PRw=.b2c037c8-f6c3-472b-977c-ad55ceeb5939@github.com>
Message-ID: <h7rEtEtX-O-KtH6CcMU5-Pp7zOjYlT_tB41ARNNEFKc=.93556cb3-64fd-4565-9df0-a75ac05fea49@github.com>

On Mon, 6 Feb 2023 01:06:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
>> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
>> 
>> * HotSpot
>>     * stubGenerator_x86_64_poly.cpp
>>     * elfFile.hpp
>> * libfontmanager
>>     * hb.hh
>> * libfreetype
>>     * afblue.c
>> 
>> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.
>
> Sorry Yasumasa, but I'd much prefer to see this split into three sub-tasks (or issues) just so we can keep the issues more clearly separated.
> 
> IIUC for stubGenerator_x86_64_poly.cpp we have a multiplication symbol instead of an ascii 'x' (likely pasted from a word processing document).
> 
> For elfFile.hpp there are smart-quotes instead of ascii "
> 
> Thanks.

@dholmes-ora I splitted this in three sub tasks as #12435, #12436, #12437.  
I hope they are reviewed and merged.

So I close this PR (but I do not close this issue on JBS until all subtasks are resolved).

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

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


From ysuenaga at openjdk.org  Mon Feb  6 12:40:05 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 6 Feb 2023 12:40:05 GMT
Subject: Withdrawn: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
Message-ID: <UmijvS_DQJhUKJQKPpMwxP0PCTJ38dknwpTaU1buuNY=.a3ec3ec9-dbf6-47e8-ac44-bb91cbfb19e2@github.com>

On Sat, 4 Feb 2023 09:42:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
> 
> * HotSpot
>     * stubGenerator_x86_64_poly.cpp
>     * elfFile.hpp
> * libfontmanager
>     * hb.hh
> * libfreetype
>     * afblue.c
> 
> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

This pull request has been closed without being integrated.

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

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


From ysuenaga at openjdk.org  Mon Feb  6 12:42:43 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 6 Feb 2023 12:42:43 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on Windows
Message-ID: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>

This is subtask of https://github.com/openjdk/jdk/pull/12427 .

I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)


d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????


I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

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

Commit messages:
 - 8301854: C4819 warnings were reported in libfreetype on Windows

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

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


From ysuenaga at openjdk.org  Mon Feb  6 12:44:24 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 6 Feb 2023 12:44:24 GMT
Subject: RFR: 8301855: C4819 warnings were reported in harfbuzz on Windows
Message-ID: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>

This is subtask of https://github.com/openjdk/jdk/pull/12427 .

I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)


d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????


I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

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

Commit messages:
 - 8301855: C4819 warnings were reported in harfbuzz on Windows

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

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


From asotona at openjdk.org  Mon Feb  6 12:44:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 12:44:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <xWZSZo4TZ9iFr1eJSCmR7rd3Qw3pX78wwyjZfO79N20=.1ce95c71-7267-4f56-bd21-141301e64b6f@github.com>

On Fri, 3 Feb 2023 17:22:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 75:
> 
>> 73:      * The kind of target on which the annotation appears.
>> 74:      */
>> 75:     public enum TargetType {
> 
> My IDE says this enum is not being used. I tend to believe it, since the TargetInfo sealed interface also seems to model the same thing?

There is only one TargetInfo for all TargetTypes, so instead of 22 sub-interfaces of TargetInfo, the instance of TargetType enum is hold in TargetInfo.

> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 577:
> 
>> 575: 
>> 576:     /**
>> 577:      * type_path.path.
> 
> The javadoc in this class seems off

will fix, thanks

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

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


From asotona at openjdk.org  Mon Feb  6 12:59:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 12:59:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <WYk_uF6k545myEF_jlt-3hWca2kkbTeCMzUMWjoennI=.cdf77ab2-81a2-42a3-b47c-81be7d981f51@github.com>

On Fri, 3 Feb 2023 17:23:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 641:
> 
>> 639:         int typeArgumentIndex();
>> 640: 
>> 641:         static TypePathComponent of(int typePathKind, int typeArgumentIndex) {
> 
> Should this take a `Kind` instead of an `int`?

Yes, will fix, thanks.

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

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


From asotona at openjdk.org  Mon Feb  6 13:02:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:02:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <Sd27fH9teWjwNVcNtVhEm5bGcOYA1zo14GR1Zz26Bbs=.4bac577d-bb01-49ac-b585-29758b816759@github.com>

On Fri, 3 Feb 2023 17:20:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 617:
> 
>> 615:         }
>> 616: 
>> 617:         public static final TypePathComponent ARRAY = new UnboundAttribute.TypePathComponentImpl(Kind.ARRAY, 0);
> 
> `public static final` is redundant here (it's an interface) - please check these (I've seen others). E.g. all `public` modifier for types nested in interfaces are redundant as well.

yes, will fix and search for other such cases, thanks.

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

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


From asotona at openjdk.org  Mon Feb  6 13:21:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:21:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <0w7b4dGcbkGxU1JL3pmoyjaXA2U91cwyp9Ule0uu_q4=.4e29b9c0-47e3-4ed9-9110-338d13ab9db1@github.com>

On Fri, 3 Feb 2023 17:32:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/SignatureAttribute.java line 66:
> 
>> 64: 
>> 65:     /**
>> 66:      * Parse the siganture as a method signature.
> 
> typo here `siganture` - check the entire class

will fix, thanks

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

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


From asotona at openjdk.org  Mon Feb  6 13:29:10 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:29:10 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - javadoc fixes
 - obsolete identifiers and unused imports cleanup
 - TypeAnnotation.TypePathComponent cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/8df1dc21..1aabe0e3

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

  Stats: 32 lines in 9 files changed: 8 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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


From asotona at openjdk.org  Mon Feb  6 13:29:14 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:29:14 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <o5D1SoQKDn5rezslHFUV7H-P63htmA2s0XXUe3xDjUE=.5cab2bd2-926c-4222-8885-df9e913c6c95@github.com>

On Fri, 3 Feb 2023 17:37:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/package-info.java line 39:
> 
>> 37:  * <p>
>> 38:  * {@snippet lang=java :
>> 39:  * ClassModel cm = ClassModel.of(bytes);
> 
> There are several references to `ClassModel::of` (here and elsewhere), but this seems to have been moved to `ClassFile::parse`

will fix, thanks

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

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


From asotona at openjdk.org  Mon Feb  6 13:45:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:45:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <WtoD_37G0yKzxNTqSuaGNGsfEt35H7lXw16z_lg9S8k=.a623b8ee-2db5-4157-8db5-4f80fe92f05b@github.com>

On Fri, 3 Feb 2023 17:43:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 58:
> 
>> 56:  * Main entry points for parsing, transforming, and generating classfiles.
>> 57:  */
>> 58: public class Classfile {
> 
> class or interface? (bikeshed, I realize)

yes, a bikeshed

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 197:
> 
>> 195:      * @return the classfile bytes
>> 196:      */
>> 197:     public static byte[] build(ClassDesc thisClass,
> 
> The "build" methods here seem regular - e.g. build { class, module } x { byte array, path }. As a future improvement, perhaps capturing the "sink" of a build process might be helpful - so that you can avoid overloads between array and path variants. (e.g. `build(.... toByteArray(arr))`, or `build(...).toByteArray(...)`.

Classfile::build always return byte array and there is no "sink" model inside.
Classfile::buildTo is frequently used extension; a wrapper calling build and writing the byte array using Files::write.

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

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


From ihse at openjdk.org  Mon Feb  6 13:51:49 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 6 Feb 2023 13:51:49 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <4P8uUwzk0rgPNXiw-3LEkWcbvzepHojoVDJDYz0ilsU=.55f4d537-6a77-489d-a40c-e26a0aaa9416@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

So to add some context to this and the related PRs.  **C4819** has this official description:

`The file contains a character that cannot be represented in the current code page (number). Save the file in Unicode format to prevent data loss.`

So, this is not so much a compilation error per se, but a problem with the encoding of our source code files.

Some time ago, there were a discussion that we should make sure our code base where in utf-8, instead of the current unspecified state of "mostly ascii, but some additional characters but we won't tell you which encoding, hopefully it's latin-1". 

I'm thinking the correct choice is maybe not to silence the warning, but to actually put down our collective feet, say "enough is enough of this nonsense!", declare the source to be utf-8, turn on all flags needed to get our tools to recognize this fact, and then go on with our lives.

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

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


From asotona at openjdk.org  Mon Feb  6 13:52:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:52:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <2dfIIfnZwgc-wezRVH81l9b5VjLjP02k7PjU64wjAww=.5c9e7ba6-4254-46cd-a6c0-553dcea7dc3b@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <2dfIIfnZwgc-wezRVH81l9b5VjLjP02k7PjU64wjAww=.5c9e7ba6-4254-46cd-a6c0-553dcea7dc3b@github.com>
Message-ID: <F9Z-fMHgQtKGeEZu3jv2V7dTEmGVnfY28dFLu5sIS7Q=.3a6db219-3ae0-4352-a146-0ac45820b1a1@github.com>

On Fri, 3 Feb 2023 18:07:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 346:
>> 
>>> 344:     public static final int MAGIC_NUMBER = 0xCAFEBABE;
>>> 345: 
>>> 346:     public static final int NOP             = 0;
>> 
>> Not sure how I feel about the constants being here. It seems to me that they can be moved to more appropriate places - e.g. Instructor, TypeAnnotation (for the TAT ones), ConstantPool (for the TAG ones).
>> 
>> The classfile versions, OTOH, do seem to belong here.
>
> Actually, we also have a ClassfileVersion class, so that could be a better place for version numbers?

There were several iterations of "where to store numeric constants".
It is hard to find them when spread across many classes and duplicities appear instantly.
Dedicated "Constants" would be another bikeshed with conflicting name.
Co-location in Classfile was the latest decission as it is not just a central bikeshed, but it also reflect connection with classfile specification.
Please raise that discussion at classfile-api-dev at openjdk.org if necessary.

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

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


From asotona at openjdk.org  Mon Feb  6 13:58:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 13:58:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>

On Fri, 3 Feb 2023 17:52:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/AttributedElement.java line 94:
> 
>> 92:      * are permitted.
>> 93:      */
>> 94:     enum Kind {
> 
> Not sure how to interpret this. This seems to refer to an attribute - e.g. where is an attribute allowed - rather than to the element (e.g. the declaration to which the attribute is attached). All the constants are unused, so hard to make sense of how this is used.

There are at least 72 usages of AttributedElement.Kind across the Classfile API.
Do you suggest to rename it to something else (for example Location)?

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

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


From asotona at openjdk.org  Mon Feb  6 14:04:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:04:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <Bgo7s5q6imUmwyWqUY4rLqXfpzEYz7xTrPp_VBdOhsQ=.850f98ce-8689-4ae2-b032-50d2916fcc25@github.com>

On Fri, 3 Feb 2023 17:56:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/Attributes.java line 774:
> 
>> 772:      */
>> 773:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
>> 774:         int hash = name.hashCode();
> 
> If we have a map, why do we need this "inlined" map here? Performance reasons?

Yes, performance is the main reason.
I'll note to do a fresh differential performance benchmarks with a HashMap.

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

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


From asotona at openjdk.org  Mon Feb  6 14:11:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:11:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <iJyGP0x-bzXtRchGky3D7nJr-J2k4XPtl64FjcXJtCQ=.a9d4c1cd-08a7-4b8b-b43e-57a264d7265c@github.com>

On Fri, 3 Feb 2023 17:58:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/BootstrapMethodEntry.java line 41:
> 
>> 39:  * part of the constant pool.
>> 40:  */
>> 41: public sealed interface BootstrapMethodEntry
> 
> Usages of this seem all to fall into the `constantpool` package - does this interface belong there?

`BootstrapMethodEntry` is not a constant pool entry, but `BootstrapMethodsAttribute` entry.
It might be rather moved under `attribute` package and renamed to `BootstrapMethodInfo` to follow the same pattern as other attributes/infos.

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

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


From asotona at openjdk.org  Mon Feb  6 14:16:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:16:59 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <8tqh8yQ47KA2UrWlPItUcFMQ97uvNXCiCJUj-PDksJo=.c9e71d26-15ef-4915-8317-651337a23af9@github.com>

On Fri, 3 Feb 2023 17:59:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/BufWriter.java line 40:
> 
>> 38:  * to the end of the buffer, as well as to create constant pool entries.
>> 39:  */
>> 40: public sealed interface BufWriter
> 
> What is the relationship between this and ClassReader? Is one the dual of the other - e.g. is the intended use for BufWriter to write custom attributes, whereas ClassReader reads custom attributes?

Yes, it is an exposure of low-level API to support custom attributes.

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

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


From asotona at openjdk.org  Mon Feb  6 14:29:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:29:04 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <V9_FdxdSeOeFwSCRWE9yMBtOPXh57tf7eJuLl_qw0H0=.0a954224-a444-4cde-bc47-8a37f275721b@github.com>

On Fri, 3 Feb 2023 18:11:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/ClassModel.java line 104:
> 
>> 102:      * found
>> 103:      */
>> 104:     default List<VerifyError> verify(Consumer<String> debugOutput) {
> 
> not super sure whether `verify` belongs here - could be another component in the `components` package?

Classfile API by default does not verify produced or transformed bytecode, so this is more a question if we want to have verification an integral part of the API or a standalone tool.

> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 613:
> 
>> 611:     }
>> 612: 
>> 613:     default CodeBuilder labelBinding(Label label) {
> 
> Maybe just `bind` or `bindLabel` ?

It has been discussed (and changed) many times. Please raise this discussion at classfile-api-dev at openjdk.org

> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1371:
> 
>> 1369:     }
>> 1370: 
>> 1371:     default CodeBuilder tableswitch(Label defaultTarget, List<SwitchCase> cases) {
> 
> `switch` seems the one instruction for which an high-level variant (like `trying`) could be useful, as generating code for that can be quite painful.

Nice RFE, thanks.

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

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


From asotona at openjdk.org  Mon Feb  6 14:35:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 14:35:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>

On Fri, 3 Feb 2023 18:37:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/ClassSignature.java line 34:
> 
>> 32:  * Models the generic signature of a class file, as defined by JVMS 4.7.9.
>> 33:  */
>> 34: public sealed interface ClassSignature
> 
> It is a bit odd to have Signature and XYZSignature in the API with the latter not extending the former. I think I get what the API is aiming for though - e.g. Signature is for modelling low-level "portions" of the signature attributes, whereas ClassSignature, MethodSignature and friends are there to model the signature attribute attached to a class, method, etc.

The confusion come from simplified name. Signature probably should be called JavaTypeSignature according to the spec. ClassSignature and MethodSignature could not extend it, as it would not respect the reality. Each of them are completely different species. Signature (or JavaTypeSignature) on the other side has many sub-types.

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

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


From duke at openjdk.org  Mon Feb  6 15:57:01 2023
From: duke at openjdk.org (altrisi)
Date: Mon, 6 Feb 2023 15:57:01 GMT
Subject: RFR: 8301834: Templated Buffer classes leave a lot of empty lines
 in the generated source
In-Reply-To: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
References: <NShlonPoOpwt90csJyyyz71GUhwMkuVuXi1Ev8p8jcE=.17eec3ac-280e-4abc-9c39-76753c62d14f@github.com>
Message-ID: <3ebCEPYLnPp4ZzR3-qPt0oLtVpi_1PoSy8F0Wh4MMw8=.3b261957-848f-4d0a-a2ee-76a2d9c27b74@github.com>

On Mon, 6 Feb 2023 06:57:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8301834?
> 
> Some classes in `java.nio` package are generated from template files, during the build. The template files are processed by a build tool implemented by a Java class `make/jdk/src/classes/build/tools/spp/Spp.java`. This template processing tool allows for an (optional) parameter called `-nel` which as per its documentation:
> 
>>  If -nel is declared then empty lines will not be substituted for lines of
>>  text in the template that do not appear in the output.
> 
> Various places in the JDK build where this tool is used to generate source from template files, already use the `-nel` option to not generate the empty lines in the source files. However, the `GensrcBuffer.gmk` which generates the source for `java.nio` classes doesn't use this option. The commit in this PR adds this option when generating the `java.nio` classes.
> 
> Existing tests in `test/jdk/java/nio` continue to pass after this change. I've checked the generated content and compared it with the older versions to verify that these empty lines no longer appear in these generated classes.
> 
> Additional `tier` testing has been triggered to make sure no regression is introduced.

Would it be feasible (and useful) to maybe just in release builds have these removed? Or maybe create some mappings to the templates for the debugging purposes? Some classes get very unreadable with these.

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

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


From prr at openjdk.org  Mon Feb  6 17:14:49 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Feb 2023 17:14:49 GMT
Subject: RFR: 8301855: C4819 warnings were reported in harfbuzz on Windows
In-Reply-To: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
References: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
Message-ID: <KuxhuPLyqOFum-vJF-ffkOhYK-ccvd0m2Z_xncwxtAI=.ae0c5280-f4c2-45ce-b74d-367b2e0d8855@github.com>

On Mon, 6 Feb 2023 12:35:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

I notice you didn't bother telling folks what this warning is 
It is
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4819?view=msvc-170
"The file contains a character that cannot be represented in the current code page (number)."

JDK does not support being built in arbitrary locales. 
And the warning comes from hb.hh at some line you don't reveal so I can't tell if its in a comment or something more critical, and then since its in a central header file I can't tell if its the only such warning or not.

This fix is rejected. Build in an English locale.

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

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


From prr at openjdk.org  Mon Feb  6 17:17:48 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Feb 2023 17:17:48 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <V34xPoVNUSEJTPjqyo3b-E37g8zkhJQyEnhQjaHqjaQ=.33558041-c68f-49a0-9423-9d057ef21047@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

Fix rejected for the same reasons as described in https://github.com/openjdk/jdk/pull/12437

" declare the source to be utf-8, "

you can't do that if you don't own the code, can you ?
Regardless this fix isn't right.

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

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


From asotona at openjdk.org  Mon Feb  6 23:24:28 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Feb 2023 23:24:28 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <72tbazC88v5YoHtiss3ZJ6bmRP02sRG1j6-h9q752fc=.2acd02a8-018c-45d5-b65d-7089c1819815@github.com>

On Fri, 3 Feb 2023 18:25:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 333:
> 
>> 331:          * @see #catchingAll
>> 332:          */
>> 333:         CatchBuilder catching(ClassDesc exceptionType, Consumer<BlockCodeBuilder> catchHandler);
> 
> I imagine there are name clashes with Java keyword, hence the `ing` in the names. That said, this should probably revisited in a later bikeshedding round - as in the current form, the code builder API has most method names that are nouns (the thing being built) but it also has some verbs in there (trying, catching) which seem odd.

Please raise the naming convention discussion at classfile-api-dev at openjdk.org
Thanks.

> src/java.base/share/classes/jdk/internal/classfile/Opcode.java line 39:
> 
>> 37:  */
>> 38: public enum Opcode {
>> 39:     NOP(Classfile.NOP, 1, Kind.NOP),
> 
> This also duplicates the constants in classfile...

On the contrary, it has been deduplicated. Opcode is referencing numeric constants stored in Classfile.

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

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


From ysuenaga at openjdk.org  Tue Feb  7 00:04:19 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Feb 2023 00:04:19 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

I grep'ed (with `-i`) in `doc` directory with `LANG`, `utf`, `locale`, but I could not find out them. I guess locale of build environment is not mentioned clearly. Is it correct?

I agree with you to use English locale (e.g. `LANG=C`) is prefered, but I guess may difficult when we use WSL because `LANG` is not propergate to Windows environment.

I confirmed that it is succeeded to build with `--with-extra-cflags=/utf-8 --with-extra-cxxflags=/utf-8`, so I think it is better to add them to build option for Windows by default, but I'm not sure it is correct because no documents mention to the locale. What do you think?

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

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


From prr at openjdk.org  Tue Feb  7 01:14:44 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Feb 2023 01:14:44 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
 <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
Message-ID: <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>

On Tue, 7 Feb 2023 00:01:56 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I grep'ed (with `-i`) in `doc` directory with `LANG`, `utf`, `locale`, but I could not find out them. I guess locale of build environment is not mentioned clearly. Is it correct?
> 
> I agree with you to use English locale (e.g. `LANG=C`) is prefered, but I guess may difficult when we use WSL because `LANG` is not propergate to Windows environment.
> 
> I confirmed that it is succeeded to build with `--with-extra-cflags=/utf-8 --with-extra-cxxflags=/utf-8`, so I think it is better to add them to build option for Windows by default, but I'm not sure it is correct because no documents mention to the locale. What do you think?

I don't know if it is documented but it has been discussed multiple times over the years.
Which encodings are *supposed* to work would be a good thing to document, LANG=C isn't strictly "English" and LC_* vars over-ride it
but "en_US-iso-8859-1" (eg) definitely should work, because that or some close equivalent (windows cp1252 or maybe 1250) are what we've considered as "must work" (SFAIK) 

If the build team want to make utf-8 the default encoding and it can be done  without having to worry unduly about 3rd party code and what might be in the repo today then that would be a good thing I expect.
But it is a bigger conversation than this PR

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

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


From ysuenaga at openjdk.org  Tue Feb  7 02:48:44 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Feb 2023 02:48:44 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
 <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
 <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
Message-ID: <UK4JI5dvB9AtHpcqTf3CW0TM7nEWxeF6txN8C-IUVxc=.7060f3fb-5e23-4e25-bc70-f431e4527fa5@github.com>

On Tue, 7 Feb 2023 01:12:06 GMT, Phil Race <prr at openjdk.org> wrote:

> but "en_US-iso-8859-1" (eg) definitely should work, because that or some close equivalent (windows cp1252 or maybe 1250) are what we've considered as "must work" (SFAIK)

According to Wikipedia article of [CP1250](https://en.wikipedia.org/wiki/Windows-1250) and [CP1252](https://en.wikipedia.org/wiki/Windows-1252), characters in 9x is not available in [8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1), and  I saw this error in `?` (0x93) and `?` (0x94).

So I think to use UTF-8 should be documented, and it is better to add `/utf-8` to `CFLAGS` / `CXXFLAGS` for Windows if we can.

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

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


From prr at openjdk.org  Tue Feb  7 03:58:41 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Feb 2023 03:58:41 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <UK4JI5dvB9AtHpcqTf3CW0TM7nEWxeF6txN8C-IUVxc=.7060f3fb-5e23-4e25-bc70-f431e4527fa5@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
 <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
 <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
 <UK4JI5dvB9AtHpcqTf3CW0TM7nEWxeF6txN8C-IUVxc=.7060f3fb-5e23-4e25-bc70-f431e4527fa5@github.com>
Message-ID: <nXvj-1SdQOXY7BFgVRrsGj5ItlbUehknEiAKKVCkZac=.ee391d1d-294c-4870-b626-ccdd839226be@github.com>

On Tue, 7 Feb 2023 02:46:10 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> > but "en_US-iso-8859-1" (eg) definitely should work, because that or some close equivalent (windows cp1252 or maybe 1250) are what we've considered as "must work" (SFAIK)
> 
> According to Wikipedia article of [CP1250](https://en.wikipedia.org/wiki/Windows-1250) and [CP1252](https://en.wikipedia.org/wiki/Windows-1252), characters in 9x is not available in [8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1), and I saw this error in `?` (0x93) and `?` (0x94).
> 
> So I think to use UTF-8 should be documented, and it is better to add `/utf-8` to `CFLAGS` / `CXXFLAGS` for Windows if we can.

So let's say it is the compatible subset.

Regardless, take this to the build team as a separate PR to find a JDK-wide
solution. No disabling warnings in random libraries

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

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


From haosun at openjdk.org  Tue Feb  7 06:17:14 2023
From: haosun at openjdk.org (Hao Sun)
Date: Tue, 7 Feb 2023 06:17:14 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <VFi-Q8AqSpe1D0Go6eIFEfE8okl9Z6V95rNL4AAH8Ag=.e0f4ce27-e49d-450e-83ef-b2d2d4bd60d4@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
 <-RReNBa4rbWMG38xuIH_yCfzDDEubd4gU2QsVCdiubM=.0e13582c-f1c8-4e35-a1ce-174a22b86a58@github.com>
 <4v4pdOt2xrFJx30NbLByS6jw3p_y3NSutAxIQq_I-lg=.cedfdf56-6a23-46b6-8cd3-044a467c2c61@github.com>
 <VFi-Q8AqSpe1D0Go6eIFEfE8okl9Z6V95rNL4AAH8Ag=.e0f4ce27-e49d-450e-83ef-b2d2d4bd60d4@github.com>
Message-ID: <lKUWLsbmR2xGUIHS68R70sTrqBkvAPbLEecpwgnfUUk=.d8717642-34c9-48d1-9692-e5389593535d@github.com>

On Mon, 6 Feb 2023 11:50:57 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Thanks for reporting this. @dougxc 
>> 
>> Yes. I encountered several jtreg failures with Graal, which is built with PAC-RET enabled JDK.
>> 
>> As I see it, the straightforward fix is to disable JVMCI if `_rop_protection` is parsed as "true" finally, since Graal doesn't supports PAC-RET currently. 
>> That is similar to the way `JVMCIGlobals::check_jvmci_supported_gc` does, i.e. if one GC except `G1/Serial/Parallel` is configured, we disable JVMCI.
>> WDYT
>
> The problem with `JVMCIGlobals::check_jvmci_supported_gc` is that it does not give the compiler a chance to specify whether it supports a given GC.
> Instead, we want a JVMCI upcall like `jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.isGCSupported(int)`.

Thanks for your reply. But I'm afraid I'm still a bit confused.

1) flag `_rop_protection` is set inside function `VM_Version::initialize()`. The execution flow is `create_vm -> init_globals -> VM_Version_init -> VM_Version::initialize()`.
2) I suppose compilers (including JVMCI compiler) are initialized after `init_global()` function. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/threads.cpp#L685~L707. Hence I suppose we cannot call JVMCI methods before this site, right?

If so, I'm afraid it's a bit late for VM to ask the compiler whether it supports PAC-RET after the compiler initialization, and to disable PAC-RET if the JVMCI compiler doesn't support it, mainly because some stubs are generated already between `init_global()` and compiler initialization, and in these stubs, flag `_rop_protection` is used to generate PAC-related code, e.g., `SharedRuntime::generate_stubs() -> generate_deopt_blob() -> protect_return_address()`.

Please correct me if there is something I misunderstood. Thanks.

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

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


From dnsimon at openjdk.org  Tue Feb  7 07:59:14 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 7 Feb 2023 07:59:14 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <lKUWLsbmR2xGUIHS68R70sTrqBkvAPbLEecpwgnfUUk=.d8717642-34c9-48d1-9692-e5389593535d@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
 <-RReNBa4rbWMG38xuIH_yCfzDDEubd4gU2QsVCdiubM=.0e13582c-f1c8-4e35-a1ce-174a22b86a58@github.com>
 <4v4pdOt2xrFJx30NbLByS6jw3p_y3NSutAxIQq_I-lg=.cedfdf56-6a23-46b6-8cd3-044a467c2c61@github.com>
 <VFi-Q8AqSpe1D0Go6eIFEfE8okl9Z6V95rNL4AAH8Ag=.e0f4ce27-e49d-450e-83ef-b2d2d4bd60d4@github.com>
 <lKUWLsbmR2xGUIHS68R70sTrqBkvAPbLEecpwgnfUUk=.d8717642-34c9-48d1-9692-e5389593535d@github.com>
Message-ID: <A80pOpspvsqTsJ1cEAnFqowZ1vasl5R6BDwUlgXj20E=.61fcb078-89fd-410e-aca8-646464852510@github.com>

On Tue, 7 Feb 2023 06:14:24 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> The problem with `JVMCIGlobals::check_jvmci_supported_gc` is that it does not give the compiler a chance to specify whether it supports a given GC.
>> Instead, we want a JVMCI upcall like `jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.isGCSupported(int)`.
>
> Thanks for your reply. But I'm afraid I'm still a bit confused.
> 
> 1) flag `_rop_protection` is set inside function `VM_Version::initialize()`. The execution flow is `create_vm -> init_globals -> VM_Version_init -> VM_Version::initialize()`.
> 2) I suppose compilers (including JVMCI compiler) are initialized after `init_global()` function. See https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/threads.cpp#L685~L707. Hence I suppose we cannot call JVMCI methods before this site, right?
> 
> If so, I'm afraid it's a bit late for VM to ask the compiler whether it supports PAC-RET after the compiler initialization, and to disable PAC-RET if the JVMCI compiler doesn't support it, mainly because some stubs are generated already between `init_global()` and compiler initialization, and in these stubs, flag `_rop_protection` is used to generate PAC-related code, e.g., `SharedRuntime::generate_stubs() -> generate_deopt_blob() -> protect_return_address()`.
> 
> Please correct me if there is something I misunderstood. Thanks.

Ah ok, I did not pay attention to the VM lifecycle constraints in setting this flag. We could do the JVMCI check in `CompileBroker::compilation_init_phase2` but that would mean forcing eager initialization of JVMCI which, in turn, would impact VM startup.
For now, we will just add a check into Graal that `UseBranchProtection` is not set, exiting the VM if it is. At the same time, we will work on adding support for this.

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

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


From djelinski at openjdk.org  Tue Feb  7 08:01:48 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 7 Feb 2023 08:01:48 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v2]
In-Reply-To: <E7Uak5J0FFV1ik7CMYbs3Z87N_15lGVRcs5ZTsBtWhE=.1f760cef-d01b-446f-b6bc-4f7248ddccf0@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
 <E7Uak5J0FFV1ik7CMYbs3Z87N_15lGVRcs5ZTsBtWhE=.1f760cef-d01b-446f-b6bc-4f7248ddccf0@github.com>
Message-ID: <vJetAJWOKG6XLWPgcTRbViLLFBHZR7FsDol0oOYV5v0=.6a71b07b-a7ee-4ad4-ad15-eb29e4732f51@github.com>

On Fri, 20 Jan 2023 12:01:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
>> 
>> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge remote-tracking branch 'origin' into awt-warning-cleanup
>  - Copyright
>  - snprintf
>  - cl analyze
>  - Fix non-debug warning
>  - Restore suppressions
>  - Fix warnings
>  - WIP: reenable awt warnings
>  - Fix warnings

keep alive / waiting for review from client-libs...

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

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


From duke at openjdk.org  Tue Feb  7 10:02:20 2023
From: duke at openjdk.org (Alan Hayward)
Date: Tue, 7 Feb 2023 10:02:20 GMT
Subject: RFR: 8277204: Implement PAC-RET branch protection on Linux/AArch64
 [v25]
In-Reply-To: <A80pOpspvsqTsJ1cEAnFqowZ1vasl5R6BDwUlgXj20E=.61fcb078-89fd-410e-aca8-646464852510@github.com>
References: <Incu1NvV4G3SROSqBQmwIW3kTMb3dzEMvQFLeLAvmng=.c433cad4-5540-4fe9-b4bb-991b8597d973@github.com>
 <PznyMgwgokS2upKnYF7pz76MrXv90aaJBh1h1JGa4Nw=.95b08dfa-68cf-447e-a7d2-66cd34ff05de@github.com>
 <-RReNBa4rbWMG38xuIH_yCfzDDEubd4gU2QsVCdiubM=.0e13582c-f1c8-4e35-a1ce-174a22b86a58@github.com>
 <4v4pdOt2xrFJx30NbLByS6jw3p_y3NSutAxIQq_I-lg=.cedfdf56-6a23-46b6-8cd3-044a467c2c61@github.com>
 <VFi-Q8AqSpe1D0Go6eIFEfE8okl9Z6V95rNL4AAH8Ag=.e0f4ce27-e49d-450e-83ef-b2d2d4bd60d4@github.com>
 <lKUWLsbmR2xGUIHS68R70sTrqBkvAPbLEecpwgnfUUk=.d8717642-34c9-48d1-9692-e5389593535d@github.com>
 <A80pOpspvsqTsJ1cEAnFqowZ1vasl5R6BDwUlgXj20E=.61fcb078-89fd-410e-aca8-646464852510@github.com>
Message-ID: <-k2uQ-TURI9crzECbTiEo2JyJxq9r2yBuo3iP_NEVt8=.5e548bc8-d8ef-41c9-8a53-e7d1d6f1109e@github.com>

On Tue, 7 Feb 2023 07:55:58 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>For now, we will just add a check into Graal that UseBranchProtection is not set, exiting the VM if it is

that sounds a better solution to me instead of:

> disable JVMCI if _rop_protection is parsed as "true"

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

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


From suenaga at oss.nttdata.com  Tue Feb  7 11:25:42 2023
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Tue, 7 Feb 2023 20:25:42 +0900
Subject: RFC: Set UTF-8 as source file encoding on Windows
Message-ID: <5dd30149-0ecf-2e62-bc89-32a5794620fe@oss.nttdata.com>

Hi all,

We are discussing about source file encoding in PR #12436 [1]

I saw some C4819 warnings on Windows when I tried to build OpenJDK on Windows with Japanese locale (CP932). C4819 means the source file contains characters which cl.exe cannot be handled in the current code page (CP932 in my case).

I proposed to suppress C4819 in PR #12436, #12437 [2], and #12435 [3]. I heared JDK folks have discussed about source file encoding in some times, and it looks like that we expect UTF-8.
So I want to propose to add `-utf-8` to CFLAGS for Windows. What do you think?

The change is here: https://github.com/YaSuenag/jdk/commit/272678f8f0a74d893d98b507f2c0562bff900b9d


In GCC, the compiler expects UTF-8 as a source file encoding [4].
OTOH cl.exe will use current user code page when the source does not have BOM [5] in Windows. So I think we should think about Linux (in other platforms eg macOS, I guess we can ignore because we haven't see any reports which relate to the locale, and they can be set the locale straightly - WSL cannot do so).

This proposal affects all native components in JDK, so I want to discuss about this topic before filing this to JBS and sending PR for this.


And also I think we should describe about source file encoding in some place. It may be "Operating System Requirements" in building.md . Let me know if better place.


Thanks,

Yasumasa



[1] https://github.com/openjdk/jdk/pull/12436
[2] https://github.com/openjdk/jdk/pull/12437
[3] https://github.com/openjdk/jdk/pull/12435
[4] https://gcc.gnu.org/onlinedocs/gcc-12.2.0/cpp/Character-sets.html
[5] https://learn.microsoft.com/en-us/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8?view=msvc-170


From mcimadamore at openjdk.org  Tue Feb  7 11:43:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 11:43:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <xWZSZo4TZ9iFr1eJSCmR7rd3Qw3pX78wwyjZfO79N20=.1ce95c71-7267-4f56-bd21-141301e64b6f@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <xWZSZo4TZ9iFr1eJSCmR7rd3Qw3pX78wwyjZfO79N20=.1ce95c71-7267-4f56-bd21-141301e64b6f@github.com>
Message-ID: <8L9D0Rni2RoK0TMbTIe1QNqD_3qKqFPmCW_Hij6i8m4=.dfb7efd6-5a5a-42b1-908c-f3849970a0c7@github.com>

On Mon, 6 Feb 2023 12:41:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/TypeAnnotation.java line 75:
>> 
>>> 73:      * The kind of target on which the annotation appears.
>>> 74:      */
>>> 75:     public enum TargetType {
>> 
>> My IDE says this enum is not being used. I tend to believe it, since the TargetInfo sealed interface also seems to model the same thing?
>
> There is only one TargetInfo for all TargetTypes, so instead of 22 sub-interfaces of TargetInfo, the instance of TargetType enum is hold in TargetInfo.

Ok, I see that now - for some reason the IDE could not find the usage... thanks

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

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


From mcimadamore at openjdk.org  Tue Feb  7 11:51:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 11:51:53 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
Message-ID: <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>

On Mon, 6 Feb 2023 13:55:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/AttributedElement.java line 94:
>> 
>>> 92:      * are permitted.
>>> 93:      */
>>> 94:     enum Kind {
>> 
>> Not sure how to interpret this. This seems to refer to an attribute - e.g. where is an attribute allowed - rather than to the element (e.g. the declaration to which the attribute is attached). All the constants are unused, so hard to make sense of how this is used.
>
> There are at least 72 usages of AttributedElement.Kind across the Classfile API.
> Do you suggest to rename it to something else (for example Location)?

Uhm - I can't see these usages... something seems to be off with my IDE configuration. I did a grep and I now saw the uses. That said, having the Kind/Location inside AttributedElement still looks weird to me. The "places where an attribute can appear" is a property of an `Attribute`, not of an attributed element (which is used to model elements which can have attributes).

>> src/java.base/share/classes/jdk/internal/classfile/Attributes.java line 774:
>> 
>>> 772:      */
>>> 773:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
>>> 774:         int hash = name.hashCode();
>> 
>> If we have a map, why do we need this "inlined" map here? Performance reasons?
>
> Yes, performance is the main reason.
> I'll note to do a fresh differential performance benchmarks with a HashMap.

thanks

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

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


From ihse at openjdk.org  Tue Feb  7 11:52:46 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 11:52:46 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
 <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
 <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
Message-ID: <NDB4tmeUbWLGlY55m29B4qpy4jXAMzinhoxXLX0Pqlw=.3b4e2fce-d963-4767-8881-6a55d1a3d3ba@github.com>

On Tue, 7 Feb 2023 01:12:06 GMT, Phil Race <prr at openjdk.org> wrote:

> I grep'ed (with `-i`) in `doc` directory with `LANG`, `utf`, `locale`, but I could not find out them. I guess locale of build environment is not mentioned clearly. Is it correct?

Yes, it is unfortunately not documented. :-( There is an open bug about this ([JDK-8264425](https://bugs.openjdk.org/browse/JDK-8264425)) but it has repeatedly been pushed down on my todo list due to low priority. :(

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

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


From mcimadamore at openjdk.org  Tue Feb  7 11:56:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 11:56:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <iJyGP0x-bzXtRchGky3D7nJr-J2k4XPtl64FjcXJtCQ=.a9d4c1cd-08a7-4b8b-b43e-57a264d7265c@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <iJyGP0x-bzXtRchGky3D7nJr-J2k4XPtl64FjcXJtCQ=.a9d4c1cd-08a7-4b8b-b43e-57a264d7265c@github.com>
Message-ID: <qitIL4woheCXgtU3PEQiW2HgXeKxvsInBTYqJOSG3cY=.e28eda15-5eec-40e5-81c1-21c3b7b23ac4@github.com>

On Mon, 6 Feb 2023 14:09:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/BootstrapMethodEntry.java line 41:
>> 
>>> 39:  * part of the constant pool.
>>> 40:  */
>>> 41: public sealed interface BootstrapMethodEntry
>> 
>> Usages of this seem all to fall into the `constantpool` package - does this interface belong there?
>
> `BootstrapMethodEntry` is not a constant pool entry, but `BootstrapMethodsAttribute` entry.
> It might be rather moved under `attribute` package and renamed to `BootstrapMethodInfo` to follow the same pattern as other attributes/infos.

I know it's part of an attribute - but reading the javadoc:

/**
 * Models an entry in the bootstrap method table.  The bootstrap method table
 * is stored in the {@code BootstrapMethods} attribute, but is modeled by
 * the {@link ConstantPool}, since the bootstrap method table is logically
 * part of the constant pool.
 */
 ```
 
 And also, seeing the method:
 
 ```
 /**
     * {@return the constant pool associated with this entry}
     */
    ConstantPool constantPool();


It seems like the API is doing the (justifiable) trick of making BSMs look like if they are first-class CP entries (even if not specified that way in the JVMLS). I think that's a fine move, but if we go down that path we should be honest, and put this class in constantpool. At least this is my 0.02$.

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

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


From ihse at openjdk.org  Tue Feb  7 11:59:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 11:59:45 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <_c9E5NjAP1NXGjDBcuLK3cMb-F_DI27WO3f2wtYPlnI=.cf39aef7-1504-4478-9b5b-abf17bef9afd@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

I agree with Phil here. This is not the proper solution. As a workaround, you can use the configure arguments to add additional flags to the compiler. Or you can change your locale.

The proper solution is getting the source code base to a consistent UTF-8 format. This is a much larger undertaking, however.

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

Changes requested by ihse (Reviewer).

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


From ihse at openjdk.org  Tue Feb  7 12:00:47 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 12:00:47 GMT
Subject: RFR: 8301855: C4819 warnings were reported in harfbuzz on Windows
In-Reply-To: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
References: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
Message-ID: <B4S0VaqCh7hyA54qS7s2bk31jNO6ROzXj5MWKKgCi4U=.927f12a6-6b84-401f-8c71-df6c59dd8225@github.com>

On Mon, 6 Feb 2023 12:35:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

Please do not integrate this. See the other sub-tasks for discussion.

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

Changes requested by ihse (Reviewer).

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


From ihse at openjdk.org  Tue Feb  7 12:11:44 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 12:11:44 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <iqoT-P1QSo3PVg9vM1cscwbmzFKUoN6wGxSIgA21lEs=.659ffe3e-274f-4c3e-bd7f-8fcfca9c79b0@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

I have opened https://bugs.openjdk.org/browse/JDK-8301971 for converting the entire code base to UTF-8.

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

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


From mcimadamore at openjdk.org  Tue Feb  7 12:13:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 12:13:51 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
Message-ID: <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>

On Mon, 6 Feb 2023 14:32:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/ClassSignature.java line 34:
>> 
>>> 32:  * Models the generic signature of a class file, as defined by JVMS 4.7.9.
>>> 33:  */
>>> 34: public sealed interface ClassSignature
>> 
>> It is a bit odd to have Signature and XYZSignature in the API with the latter not extending the former. I think I get what the API is aiming for though - e.g. Signature is for modelling low-level "portions" of the signature attributes, whereas ClassSignature, MethodSignature and friends are there to model the signature attribute attached to a class, method, etc.
>
> The confusion come from simplified name. Signature probably should be called JavaTypeSignature according to the spec. ClassSignature and MethodSignature could not extend it, as it would not respect the reality. Each of them are completely different species. Signature (or JavaTypeSignature) on the other side has many sub-types.

I think you mean `TypeSignature` from JLS 4.3.4 ? If so, I get it. To me it looks as if "Signature" really means "TypeSignature" - then it would make sense as to why `MethodSignature::arguments` returns a `List<Signature>` (e.g. because it should be `List<TypeSignature>`, as in the spec).

Also, from a modelling perspective, I see other problems too - in the JVMS, type signatures are defined as follows:


TypeSignature:
    FieldTypeSignature
    BaseType
```    
And:


FieldTypeSignature:
    ClassTypeSignature
    ArrayTypeSignature
    TypeVariableSignature 


So I'd roughly expect a type with 4 subclasses (type, then class <: type, array <: type, tvar <: type).

But the Signature class currently has other subclasses too - such as `ThrowableSig` - which is really only an (optional) part of method signatures. And, similarly, it also has `TypeParam`, which is a part of method/class signature - but is _not_ a type signature per se.

Summing up, it seems to me that the naming issue (which is not that important) hides a bigger modelling issue.

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

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


From mcimadamore at openjdk.org  Tue Feb  7 12:17:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 12:17:53 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <72tbazC88v5YoHtiss3ZJ6bmRP02sRG1j6-h9q752fc=.2acd02a8-018c-45d5-b65d-7089c1819815@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <72tbazC88v5YoHtiss3ZJ6bmRP02sRG1j6-h9q752fc=.2acd02a8-018c-45d5-b65d-7089c1819815@github.com>
Message-ID: <otc76ggmH6uIFllMsC6ofRAvI_ZlBTbo-08MADEQa70=.b605e09d-4b69-4d5e-a359-cab60fa1216c@github.com>

On Mon, 6 Feb 2023 14:35:43 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/Opcode.java line 39:
>> 
>>> 37:  */
>>> 38: public enum Opcode {
>>> 39:     NOP(Classfile.NOP, 1, Kind.NOP),
>> 
>> This also duplicates the constants in classfile...
>
> On the contrary, it has been deduplicated. Opcode is referencing numeric constants stored in Classfile.

sure, but my question is - once you have a nice enum that is 1-1 with the opcodes - why would a client want to use the low-level opcode bytes? Shouldn't the API only deal with Opcodes? (and, in the rare occurrence where a client wants to really know the int value of an opcode, they can do e.g. `PUTSTATIC.bytecode()`)

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

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


From asotona at openjdk.org  Tue Feb  7 12:25:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 12:25:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
Message-ID: <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>

On Tue, 7 Feb 2023 11:48:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> There are at least 72 usages of AttributedElement.Kind across the Classfile API.
>> Do you suggest to rename it to something else (for example Location)?
>
> Uhm - I can't see these usages... something seems to be off with my IDE configuration. I did a grep and I now saw the uses. That said, having the Kind/Location inside AttributedElement still looks weird to me. The "places where an attribute can appear" is a property of an `Attribute`, not of an attributed element (which is used to model elements which can have attributes).

`AttributedElement::attributedElementKind` identifies the one kind of the attributes holder.
The "places where an attribute can appear" is available through `AttributeMapper::whereApplicable` and matched against `AttributedElement::attributedElementKind`.
We may consider to hide or remove this auxiliary method, as `AttributedElement::attributedElementKind` might be computed from the ClassfileElement instance type.

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

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


From mcimadamore at openjdk.org  Tue Feb  7 12:37:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 12:37:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
 <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
Message-ID: <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>

On Tue, 7 Feb 2023 12:23:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Uhm - I can't see these usages... something seems to be off with my IDE configuration. I did a grep and I now saw the uses. That said, having the Kind/Location inside AttributedElement still looks weird to me. The "places where an attribute can appear" is a property of an `Attribute`, not of an attributed element (which is used to model elements which can have attributes).
>
> `AttributedElement::attributedElementKind` identifies the one kind of the attributes holder.
> The "places where an attribute can appear" is available through `AttributeMapper::whereApplicable` and matched against `AttributedElement::attributedElementKind`.
> We may consider to hide or remove this auxiliary method, as `AttributedElement::attributedElementKind` might be computed from the ClassfileElement instance type.

Still, there seems to be a modelling issue here. The property of "where could this attribute go" is a property of the attribute. Of course, for usability reason, an AttributedElement might expose a predicate saying "I only accept attributes of these kinds". But it seems to me as if the API has this relationship backwards, due to _where_ the Kind interface is being defined. I think if `Kind` was defined in `AttributeMapper` it would be a tad easier to understand. And, perhaps, the `attributedElementKind` name should be changed to something like `applicableAttributeKinds` or something like that.

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

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


From asotona at openjdk.org  Tue Feb  7 12:48:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 12:48:51 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <otc76ggmH6uIFllMsC6ofRAvI_ZlBTbo-08MADEQa70=.b605e09d-4b69-4d5e-a359-cab60fa1216c@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <72tbazC88v5YoHtiss3ZJ6bmRP02sRG1j6-h9q752fc=.2acd02a8-018c-45d5-b65d-7089c1819815@github.com>
 <otc76ggmH6uIFllMsC6ofRAvI_ZlBTbo-08MADEQa70=.b605e09d-4b69-4d5e-a359-cab60fa1216c@github.com>
Message-ID: <e1MH_Z2M5gaGfHGOh_OSxncBMyXxPukpkfThs4wTSuo=.9dfb02a3-bdab-44e4-a4c3-e36f3b52679d@github.com>

On Tue, 7 Feb 2023 12:14:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> On the contrary, it has been deduplicated. Opcode is referencing numeric constants stored in Classfile.
>
> sure, but my question is - once you have a nice enum that is 1-1 with the opcodes - why would a client want to use the low-level opcode bytes? Shouldn't the API only deal with Opcodes? (and, in the rare occurrence where a client wants to really know the int value of an opcode, they can do e.g. `PUTSTATIC.bytecode()`)

It is the question of co-location of all numeric constants in one place in Classfile (or not).
I would agree with your proposal if the architectural decision is to decentralise the numeric constants and reduce Classfile footprint.

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

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


From asotona at openjdk.org  Tue Feb  7 13:04:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 13:04:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
 <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
 <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>
Message-ID: <gqd04f9Ou36F5o0o05spkG2JgXoyix3wDUe78xpDb6M=.e3efc999-4545-414e-9daa-73a8b67dc7fd@github.com>

On Tue, 7 Feb 2023 12:34:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `AttributedElement::attributedElementKind` identifies the one kind of the attributes holder.
>> The "places where an attribute can appear" is available through `AttributeMapper::whereApplicable` and matched against `AttributedElement::attributedElementKind`.
>> We may consider to hide or remove this auxiliary method, as `AttributedElement::attributedElementKind` might be computed from the ClassfileElement instance type.
>
> Still, there seems to be a modelling issue here. The property of "where could this attribute go" is a property of the attribute. Of course, for usability reason, an AttributedElement might expose a predicate saying "I only accept attributes of these kinds". But it seems to me as if the API has this relationship backwards, due to _where_ the Kind interface is being defined. I think if `Kind` was defined in `AttributeMapper` it would be a tad easier to understand. And, perhaps, the `attributedElementKind` name should be changed to something like `applicableAttributeKinds` or something like that.

The relation is that each `Attribute` is applicable in N `AttributedElements` and not vice versa.
For example `ClassModel::attributedElementKind` returns `CLASS` and for example `Attributes.RUNTIME_INVISIBLE_TYPE_ANNOTATIONS::applicableAttributeKinds` returns `Set.of(CLASS, METHOD, FIELD, CODE_ATTRIBUTE, RECORD_COMPONENT)`, so we know it is applicable.

However I'll try to re-visit this part of API if needed at all.

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

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


From ihse at openjdk.org  Tue Feb  7 13:23:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 13:23:45 GMT
Subject: RFR: 8301717: Remove obsolete jib profiles
In-Reply-To: <i0JMNwIGtf8qJQKmF4nqcFymwB0VbowdePt3zRKiQow=.03dfde57-c188-4f6d-92dd-aa78d9a0cb32@github.com>
References: <i0JMNwIGtf8qJQKmF4nqcFymwB0VbowdePt3zRKiQow=.03dfde57-c188-4f6d-92dd-aa78d9a0cb32@github.com>
Message-ID: <a2AuTox8KxfTVJ_sdRxaIw9pNmHZFa6IgGwf6H8yygY=.ee7817c1-273f-444f-9b8f-cbec8aaac7e1@github.com>

On Thu, 2 Feb 2023 22:44:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch removes some now obsolete jib profiles configurations.

Marked as reviewed by ihse (Reviewer).

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

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


From ihse at openjdk.org  Tue Feb  7 13:52:50 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 13:52:50 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v3]
In-Reply-To: <pyIAB3MYuJUbHYZGYObPZGfYO8C_lrGVAqP_I_Tz6k0=.2ca7885e-3be7-4933-bd8a-515c793de6a0@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <pyIAB3MYuJUbHYZGYObPZGfYO8C_lrGVAqP_I_Tz6k0=.2ca7885e-3be7-4933-bd8a-515c793de6a0@github.com>
Message-ID: <9AqbW76scQl4YzQ30Q4yzBHl3HH9R4dltSFYGP0QCTU=.e24c95da-0a04-47b1-9cc7-9353a45665eb@github.com>

On Thu, 2 Feb 2023 15:52:01 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>
> Justin King has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix grammatical error
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Update based on review and remove restriction on compressed oops and class pointers
>    
>    Signed-off-by: Justin King <jcking at google.com>

Marked as reviewed by ihse (Reviewer).

make/data/asan/asan_default_options.c line 53:

> 51: ATTRIBUTE_DEFAULT_VISIBILITY ATTRIBUTE_USED const char* __asan_default_options() {
> 52:   return
> 53: #ifndef LEAK_SANITIZER

I'm trying to understand this part. The test for `LEAK_SANITIZER` was put in place in this file, before it was ever generated by the build system..? Was this in anticipation for this PR, or intended for the user to add an extra `-DLEAK_SANITIZER` to the compiler flags manually?

Also, this patch changes the values for asan, regardless of the state of lsan. Is this required to get the lsan patch working, or is this additional, separate fixes to asan being "smuggled" into this PR? (I don't mind a certain amount of "smuggling", since sometimes it is too tedious to open a separate JBS issue for minor, separate fixes one found out during development), but it is nice to be explicit about it.

And finally, now that the if statement also has an else, maybe reverse it to an `#ifdef` instead of `#ifndef`..?

Apart from this, the build changes look good.

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

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


From mcimadamore at openjdk.org  Tue Feb  7 14:17:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 14:17:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <gqd04f9Ou36F5o0o05spkG2JgXoyix3wDUe78xpDb6M=.e3efc999-4545-414e-9daa-73a8b67dc7fd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
 <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
 <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>
 <gqd04f9Ou36F5o0o05spkG2JgXoyix3wDUe78xpDb6M=.e3efc999-4545-414e-9daa-73a8b67dc7fd@github.com>
Message-ID: <ZpKX5fdvJXIpc6r8SgzNoLIp5FMSz97Oo2R2XM0z1zE=.94b6465d-874b-4e7d-bbdf-a6976feb6606@github.com>

On Tue, 7 Feb 2023 12:59:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Still, there seems to be a modelling issue here. The property of "where could this attribute go" is a property of the attribute. Of course, for usability reason, an AttributedElement might expose a predicate saying "I only accept attributes of these kinds". But it seems to me as if the API has this relationship backwards, due to _where_ the Kind interface is being defined. I think if `Kind` was defined in `AttributeMapper` it would be a tad easier to understand. And, perhaps, the `attributedElementKind` name should be changed to something like `applicableAttributeKinds` or something like that.
>
> The relation is that each `Attribute` is applicable in N `AttributedElements` and not vice versa.
> For example `ClassModel::attributedElementKind` returns `CLASS` and for example `Attributes.RUNTIME_INVISIBLE_TYPE_ANNOTATIONS::applicableAttributeKinds` returns `Set.of(CLASS, METHOD, FIELD, CODE_ATTRIBUTE, RECORD_COMPONENT)`, so we know it is applicable.
> 
> However I'll try to re-visit this part of API if needed at all.

I understand what the API, in its current form, wants to do. IMHO, the same functionality would be better expressed if the API had a way to say:

* each attribute has a _target_, where target can be a set of CLASS, METHOD, ...
* an attribute mapper supports a set of attribute targets
* an attributed element also supports a set of attribute targets

E.g. the target of the attribute is the concept to model - then AttributeMapper and AttributedElement just happen to expose a set of supported targets, which clients can query if needed.

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

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


From asotona at openjdk.org  Tue Feb  7 14:40:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 14:40:04 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <ZpKX5fdvJXIpc6r8SgzNoLIp5FMSz97Oo2R2XM0z1zE=.94b6465d-874b-4e7d-bbdf-a6976feb6606@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
 <3BVe_gLrmvi-zHVIgeLbDiShOwtZR7VTjBclB1ajSmA=.f290f641-8002-4606-a057-200c66a034a7@github.com>
 <DT_uR31fEtDPJ-BI3G5i6_6GUV9RPf0Yt1guetkRkU4=.f5b32b65-1d36-4f66-895e-f376f6ea2d9a@github.com>
 <gqd04f9Ou36F5o0o05spkG2JgXoyix3wDUe78xpDb6M=.e3efc999-4545-414e-9daa-73a8b67dc7fd@github.com>
 <ZpKX5fdvJXIpc6r8SgzNoLIp5FMSz97Oo2R2XM0z1zE=.94b6465d-874b-4e7d-bbdf-a6976feb6606@github.com>
Message-ID: <0K15FVxXOGvJNCRa1UOHSXr8pYxi0gdGvrPsgQhzi2s=.837fe9b4-605f-4526-8c2b-0556c8dd4495@github.com>

On Tue, 7 Feb 2023 14:14:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The relation is that each `Attribute` is applicable in N `AttributedElements` and not vice versa.
>> For example `ClassModel::attributedElementKind` returns `CLASS` and for example `Attributes.RUNTIME_INVISIBLE_TYPE_ANNOTATIONS::applicableAttributeKinds` returns `Set.of(CLASS, METHOD, FIELD, CODE_ATTRIBUTE, RECORD_COMPONENT)`, so we know it is applicable.
>> 
>> However I'll try to re-visit this part of API if needed at all.
>
> I understand what the API, in its current form, wants to do. IMHO, the same functionality would be better expressed if the API had a way to say:
> 
> * each attribute has a _target_, where target can be a set of CLASS, METHOD, ...
> * an attribute mapper supports a set of attribute targets
> * an attributed element also supports a set of attribute targets
> 
> E.g. the target of the attribute is the concept to model - then AttributeMapper and AttributedElement just happen to expose a set of supported targets, which clients can query if needed.

I've prepared pull request to jdk-sandbox with complete removal of the AttributedElement.Kind and sent following note to classfile-api-dev at openjdk.org :


I would like to propose removal of AttributedElement.Kind across all Classfile API.
The AttributedElement.Kind models Attributes ?where applicable? and it is a duplication of each Attribute extending ClassElement, MethodElement, CodeElement, etc?

Classfile API is not actively using the AttributedElement.Kind except for parsing, where inappropriate AttributedElement.Kind is resolved as UnknownAttribute.

Following proposal removes all usages of AttributedElement.Kind from Classfile API:
https://github.com/openjdk/jdk-sandbox/pull/48/files

Please let me know is there are any objections.

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

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


From asotona at openjdk.org  Tue Feb  7 14:54:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 7 Feb 2023 14:54:06 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
Message-ID: <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>

On Tue, 7 Feb 2023 12:10:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The confusion come from simplified name. Signature probably should be called JavaTypeSignature according to the spec. ClassSignature and MethodSignature could not extend it, as it would not respect the reality. Each of them are completely different species. Signature (or JavaTypeSignature) on the other side has many sub-types.
>
> I think you mean `TypeSignature` from JLS 4.3.4 ? If so, I get it. To me it looks as if "Signature" really means "TypeSignature" - then it would make sense as to why `MethodSignature::arguments` returns a `List<Signature>` (e.g. because it should be `List<TypeSignature>`, as in the spec).
> 
> Also, from a modelling perspective, I see other problems too - in the JVMS, type signatures are defined as follows:
> 
> 
> TypeSignature:
>     FieldTypeSignature
>     BaseType
> ```    
> And:
> 
> 
> FieldTypeSignature:
>     ClassTypeSignature
>     ArrayTypeSignature
>     TypeVariableSignature 
> 
> 
> So I'd roughly expect a type with 4 subclasses (type, then class <: type, array <: type, tvar <: type).
> 
> But the Signature class currently has other subclasses too - such as `ThrowableSig` - which is really only an (optional) part of method signatures. And, similarly, it also has `TypeParam`, which is a part of method/class signature - but is _not_ a type signature per se.
> 
> Summing up, it seems to me that the naming issue (which is not that important) hides a bigger modelling issue.

Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)

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

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


From jcking at openjdk.org  Tue Feb  7 15:32:11 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 15:32:11 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v4]
In-Reply-To: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
Message-ID: <B98qouigJGBmWA1vowxkNjEe2MCDRuD902SdGS8NIV8=.089d71cc-6639-4174-b977-d8f7ba4cc644@github.com>

> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
> 
> **Suppressing:**
> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
> 
> **Caveats:**
> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.

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

 - Merge branch 'master' into lsan
 - Fix grammatical error
   
   Signed-off-by: Justin King <jcking at google.com>
 - Update based on review and remove restriction on compressed oops and class pointers
   
   Signed-off-by: Justin King <jcking at google.com>
 - Support CDS
   
   Signed-off-by: Justin King <jcking at google.com>
 - Merge remote-tracking branch 'upstream/master' into lsan
 - Merge remote-tracking branch 'upstream/master' into lsan
 - Merge remote-tracking branch 'upstream/master' into lsan
 - Implement initial LSAN support v2
   
   Signed-off-by: Justin King <jcking at google.com>
 - Implement initial LSAN support

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

Changes: https://git.openjdk.org/jdk/pull/12229/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12229&range=03
  Stats: 316 lines in 23 files changed: 307 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12229.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12229/head:pull/12229

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


From jcking at openjdk.org  Tue Feb  7 15:32:16 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 15:32:16 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v3]
In-Reply-To: <9AqbW76scQl4YzQ30Q4yzBHl3HH9R4dltSFYGP0QCTU=.e24c95da-0a04-47b1-9cc7-9353a45665eb@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <pyIAB3MYuJUbHYZGYObPZGfYO8C_lrGVAqP_I_Tz6k0=.2ca7885e-3be7-4933-bd8a-515c793de6a0@github.com>
 <9AqbW76scQl4YzQ30Q4yzBHl3HH9R4dltSFYGP0QCTU=.e24c95da-0a04-47b1-9cc7-9353a45665eb@github.com>
Message-ID: <0yjUgBOQkBxUw36VJricraVo_2D23j1M1tyR6NJQzF0=.3bd3aff0-f093-4011-b9db-f7e2ef87b6a2@github.com>

On Tue, 7 Feb 2023 13:49:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix grammatical error
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>>  - Update based on review and remove restriction on compressed oops and class pointers
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>
> make/data/asan/asan_default_options.c line 53:
> 
>> 51: ATTRIBUTE_DEFAULT_VISIBILITY ATTRIBUTE_USED const char* __asan_default_options() {
>> 52:   return
>> 53: #ifndef LEAK_SANITIZER
> 
> I'm trying to understand this part. The test for `LEAK_SANITIZER` was put in place in this file, before it was ever generated by the build system..? Was this in anticipation for this PR, or intended for the user to add an extra `-DLEAK_SANITIZER` to the compiler flags manually?
> 
> Also, this patch changes the values for asan, regardless of the state of lsan. Is this required to get the lsan patch working, or is this additional, separate fixes to asan being "smuggled" into this PR? (I don't mind a certain amount of "smuggling", since sometimes it is too tedious to open a separate JBS issue for minor, separate fixes one found out during development), but it is nice to be explicit about it.
> 
> And finally, now that the if statement also has an else, maybe reverse it to an `#ifdef` instead of `#ifndef`..?
> 
> Apart from this, the build changes look good.

It was in anticipation for LSan, yes. ASan by default, in the compilers, enables LSan. I always intending on doing LSan after ASan, so I pre-emptively added the macro check before defining it in the build system.

Since ASan always enables LSan, we change options based on whether it was enabled at configuration to match.

I'll switch to ifdef.

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

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


From jcking at openjdk.org  Tue Feb  7 15:35:45 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 15:35:45 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v5]
In-Reply-To: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
Message-ID: <AuGUK2-IxU-jB4_halfyJMs-dev_Wy97jjamu9gZWHw=.e63731c1-74de-49f5-a948-54421449cb73@github.com>

> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
> 
> **Suppressing:**
> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
> 
> **Caveats:**
> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Update based on review
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12229/files
  - new: https://git.openjdk.org/jdk/pull/12229/files/f3d054b5..55b8381a

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

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

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


From jcking at openjdk.org  Tue Feb  7 15:40:34 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 15:40:34 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
Message-ID: <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>

> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
> 
> **Suppressing:**
> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
> 
> **Caveats:**
> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to JDK
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12229/files
  - new: https://git.openjdk.org/jdk/pull/12229/files/55b8381a..5c79bef5

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

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

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


From jcking at openjdk.org  Tue Feb  7 15:40:36 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 15:40:36 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v4]
In-Reply-To: <B98qouigJGBmWA1vowxkNjEe2MCDRuD902SdGS8NIV8=.089d71cc-6639-4174-b977-d8f7ba4cc644@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <B98qouigJGBmWA1vowxkNjEe2MCDRuD902SdGS8NIV8=.089d71cc-6639-4174-b977-d8f7ba4cc644@github.com>
Message-ID: <twb3M1Xf0EvcrXjd_1iVEW71poX4pM_ucrqZc6uOsT4=.f7e2e406-d856-475c-af85-60244ef509c9@github.com>

On Tue, 7 Feb 2023 15:32:11 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>
> Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into lsan
>  - Fix grammatical error
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Update based on review and remove restriction on compressed oops and class pointers
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Support CDS
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Merge remote-tracking branch 'upstream/master' into lsan
>  - Merge remote-tracking branch 'upstream/master' into lsan
>  - Merge remote-tracking branch 'upstream/master' into lsan
>  - Implement initial LSAN support v2
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Implement initial LSAN support

Reverted the change to the JDK test leak, that can be done in another PR as mentioned.

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

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


From mcimadamore at openjdk.org  Tue Feb  7 16:25:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 16:25:11 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
Message-ID: <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>

On Tue, 7 Feb 2023 14:51:06 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)

The production is the same as the one I quoted, but thanks for pointing me at the correct one. So:


JavaTypeSignature:
   ReferenceTypeSignature
   BaseType 


and


ReferenceTypeSignature:
   ClassTypeSignature
   TypeVariableSignature
   ArrayTypeSignature


So, while I can expect that `ArrayTypeSignature` *is a* `Signature` (or `JavaTypeSignature`), I cannot explain why `ThrowsSignature` extends `Signature`. That doesn't seem to follow from the production. That is, if a client obtains a `Signature` and wanted to pattern match, what are the cases it should worry about? I believe the cases are the ones listed above.

One thing I missed is that e.g. `TypeParam` is *not* a signature (which is the only case among the nested classes in `Signature`). But `ThrowsSignature`, `TypeArg` and `TypeParam` are signatures even though that doesn't seem to be the case when looking at the production in the JVMS. If we want to keep these fine, but I don't think they should extend `Signature`, either directly or indirectly. That is, `Signature` should be a sealed type with 4 leaves (base-type/array/type var/class-type).

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

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


From mcimadamore at openjdk.org  Tue Feb  7 16:25:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 7 Feb 2023 16:25:25 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
Message-ID: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>

On Mon, 6 Feb 2023 13:29:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - javadoc fixes
>  - obsolete identifiers and unused imports cleanup
>  - TypeAnnotation.TypePathComponent cleanup

src/java.base/share/classes/jdk/internal/classfile/attribute/CharacterRangeInfo.java line 80:

> 78:      * well as increment and decrement expressions (both prefix and postfix).
> 79:      * <li>{@link jdk.internal.classfile.Classfile#CRT_FLOW_CONTROLLER} An expression
> 80:      * whose value will effect control flow. Flowcon in the following:

This sentence seems hard to parse. If `Flowcon` is the name of an expression in pseudocode, perhaps using `{@code}` would help.

src/java.base/share/classes/jdk/internal/classfile/attribute/CharacterRangeInfo.java line 146:

> 144:      * @param flags the range flags
> 145:      */
> 146:     static CharacterRangeInfo of(int startPc,

I get that the encoding is as per JaCoCo specification. However, I also wonder if the API should provide better accessors and or factories to let clients just reason about line/columns numbers. Or, maybe, provide static helpers to do the encoding/decoding.

src/java.base/share/classes/jdk/internal/classfile/attribute/CodeAttribute.java line 52:

> 50:     byte[] codeArray();
> 51: 
> 52:     int labelToBci(Label label);

Missing javadoc here. (also, this method looks a bit odd in here - but I see uses e.g. in ClassPrinterImpl)

src/java.base/share/classes/jdk/internal/classfile/attribute/ModuleAttribute.java line 132:

> 130:     }
> 131: 
> 132:     static ModuleAttribute of(ModuleDesc moduleName,

Some missing javadoc in this class

src/java.base/share/classes/jdk/internal/classfile/attribute/ModuleExportInfo.java line 107:

> 105:      * @param exportsTo the modules to which this package is exported
> 106:      */
> 107:     static ModuleExportInfo of(PackageEntry exports,

(Here and elsewhere) - should there be factories also taking a PackageDesc (which seems to be an extension of the ClassDesc API, but for packages) ?

src/java.base/share/classes/jdk/internal/classfile/attribute/NestMembersAttribute.java line 72:

> 70:      * @param nestMembers the member classes of the nest
> 71:      */
> 72:     static NestMembersAttribute ofSymbols(List<ClassDesc> nestMembers) {

I see that in some classes we use the `Symbols` prefix, in others we just use `of` - we should try to make the more consistent (in the future).

src/java.base/share/classes/jdk/internal/classfile/attribute/StackMapTableAttribute.java line 68:

> 66:      * A simple stack value.
> 67:      */
> 68:     public enum SimpleVerificationTypeInfo implements VerificationTypeInfo {

I note that in this class we have made the decision to model all the innards (XYZInfo) as nested classes - while in all the other cases XYZInfo are toplevel types. Moving forward, we should pick something consistent.

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

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


From jcking at openjdk.org  Tue Feb  7 17:44:49 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 7 Feb 2023 17:44:49 GMT
Subject: Integrated: JDK-8298445: Add LeakSanitizer support in HotSpot
In-Reply-To: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
Message-ID: <5dEG5OrxWtBykLpbMa6lTXYFeriLC5_JjgKj_1xoApo=.bd397254-1fbd-4898-9b1b-5b24cda4d715@github.com>

On Thu, 26 Jan 2023 17:33:28 GMT, Justin King <jcking at openjdk.org> wrote:

> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
> 
> **Suppressing:**
> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
> 
> **Caveats:**
> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.

This pull request has now been integrated.

Changeset: 27126157
Author:    Justin King <jcking at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27126157d927c5ec4354cde8f31076899691996b
Stats:     316 lines in 22 files changed: 307 ins; 0 del; 9 mod

8298445: Add LeakSanitizer support in HotSpot

Reviewed-by: erikj, ihse

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

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


From kusrinivasan at vmware.com  Tue Feb  7 19:19:43 2023
From: kusrinivasan at vmware.com (Kumar Srinivasan)
Date: Tue, 7 Feb 2023 19:19:43 +0000
Subject: JDK-8302000: jdk11u build has a very subtle race condition causing
 builds to break.
Message-ID: <IA1PR05MB8971BFDB93530CB78555C43DB5DB9@IA1PR05MB8971.namprd05.prod.outlook.com>

Hi build-team, updates-team,

We encountered a build issue since jdk 11.0.18, the root cause and possible solutions are
documented in JDK-8302000[1]. I am willing to make the change as noted in the bug.

Let me know if approach #2 or #3 is the best option, I would like
to get a consensus from the team to take the best approach.

Thanks
Kumar Srinivasan
[1] https://bugs.openjdk.org/browse/JDK-8302000

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230207/ac2b05ae/attachment.htm>

From lmesnik at openjdk.org  Tue Feb  7 21:05:53 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 7 Feb 2023 21:05:53 GMT
Subject: RFR: 8301753: AppendFile needs to add a new line to be compatible with
 old make
Message-ID: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>

The newline is added to be compatible with old make 3.81 which is still used on MacOSX.
Fixed actually by dnsimon.

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

Commit messages:
 - 8301753: AppendFile needs to add a new line to be compatible with old make

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

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


From erikj at openjdk.org  Tue Feb  7 21:11:39 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 7 Feb 2023 21:11:39 GMT
Subject: RFR: 8301753: AppendFile needs to add a new line to be compatible
 with old make
In-Reply-To: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
References: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
Message-ID: <aEY5UM38W7CFWju8ggqCU-XRKmIkfyKdnDgjF-nHYWI=.5fe4fe04-9270-4039-a4c3-b077aaf102b0@github.com>

On Tue, 7 Feb 2023 20:56:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The newline is added to be compatible with old make 3.81 which is still used on MacOSX.
> Fixed actually by dnsimon.

Marked as reviewed by erikj (Reviewer).

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

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


From dnsimon at openjdk.org  Tue Feb  7 21:42:28 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 7 Feb 2023 21:42:28 GMT
Subject: RFR: 8301753: AppendFile needs to add a new line to be compatible
 with old make
In-Reply-To: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
References: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
Message-ID: <llQmtzU_52YZDwdqs5SNhDQQhcfj-VqTOvDFnLsEZu8=.1794ae56-d2cd-40ca-9f95-ce32dd470df5@github.com>

On Tue, 7 Feb 2023 20:56:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The newline is added to be compatible with old make 3.81 which is still used on MacOSX.
> Fixed actually by dnsimon.

Marked as reviewed by dnsimon (Committer).

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

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


From david.holmes at oracle.com  Wed Feb  8 01:39:43 2023
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 8 Feb 2023 11:39:43 +1000
Subject: RFC: Set UTF-8 as source file encoding on Windows
In-Reply-To: <5dd30149-0ecf-2e62-bc89-32a5794620fe@oss.nttdata.com>
References: <5dd30149-0ecf-2e62-bc89-32a5794620fe@oss.nttdata.com>
Message-ID: <7744e34e-db44-b9fd-b86e-eba0409e9fe1@oracle.com>

Hi Yasumasa,

Please see:

https://mail.openjdk.org/pipermail/jdk-dev/2023-February/007342.html

Cheers,
David

On 7/02/2023 9:25 pm, Yasumasa Suenaga wrote:
> Hi all,
> 
> We are discussing about source file encoding in PR #12436 [1]
> 
> I saw some C4819 warnings on Windows when I tried to build OpenJDK on 
> Windows with Japanese locale (CP932). C4819 means the source file 
> contains characters which cl.exe cannot be handled in the current code 
> page (CP932 in my case).
> 
> I proposed to suppress C4819 in PR #12436, #12437 [2], and #12435 [3]. I 
> heared JDK folks have discussed about source file encoding in some 
> times, and it looks like that we expect UTF-8.
> So I want to propose to add `-utf-8` to CFLAGS for Windows. What do you 
> think?
> 
> The change is here: 
> https://github.com/YaSuenag/jdk/commit/272678f8f0a74d893d98b507f2c0562bff900b9d
> 
> 
> In GCC, the compiler expects UTF-8 as a source file encoding [4].
> OTOH cl.exe will use current user code page when the source does not 
> have BOM [5] in Windows. So I think we should think about Linux (in 
> other platforms eg macOS, I guess we can ignore because we haven't see 
> any reports which relate to the locale, and they can be set the locale 
> straightly - WSL cannot do so).
> 
> This proposal affects all native components in JDK, so I want to discuss 
> about this topic before filing this to JBS and sending PR for this.
> 
> 
> And also I think we should describe about source file encoding in some 
> place. It may be "Operating System Requirements" in building.md . Let me 
> know if better place.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> 
> [1] https://github.com/openjdk/jdk/pull/12436
> [2] https://github.com/openjdk/jdk/pull/12437
> [3] https://github.com/openjdk/jdk/pull/12435
> [4] https://gcc.gnu.org/onlinedocs/gcc-12.2.0/cpp/Character-sets.html
> [5] 
> https://learn.microsoft.com/en-us/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8?view=msvc-170


From dholmes at openjdk.org  Wed Feb  8 02:36:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Feb 2023 02:36:55 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v4]
In-Reply-To: <twb3M1Xf0EvcrXjd_1iVEW71poX4pM_ucrqZc6uOsT4=.f7e2e406-d856-475c-af85-60244ef509c9@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <B98qouigJGBmWA1vowxkNjEe2MCDRuD902SdGS8NIV8=.089d71cc-6639-4174-b977-d8f7ba4cc644@github.com>
 <twb3M1Xf0EvcrXjd_1iVEW71poX4pM_ucrqZc6uOsT4=.f7e2e406-d856-475c-af85-60244ef509c9@github.com>
Message-ID: <__4azmkEG1NJZTlUN3aQYxNvuzRMKBBEmbSoT93wB2k=.41c15e09-0fb2-4c8b-80ff-9f742df2ecf0@github.com>

On Tue, 7 Feb 2023 15:34:50 GMT, Justin King <jcking at openjdk.org> wrote:

>> Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Merge branch 'master' into lsan
>>  - Fix grammatical error
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>>  - Update based on review and remove restriction on compressed oops and class pointers
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>>  - Support CDS
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>>  - Merge remote-tracking branch 'upstream/master' into lsan
>>  - Merge remote-tracking branch 'upstream/master' into lsan
>>  - Merge remote-tracking branch 'upstream/master' into lsan
>>  - Implement initial LSAN support v2
>>    
>>    Signed-off-by: Justin King <jcking at google.com>
>>  - Implement initial LSAN support
>
> Reverted the change to the JDK test leak, that can be done in another PR as mentioned.

@jcking  and @magicus  this change was not approved by any Hotspot Reviewer prior to integration. AFAICS the discussion with @tstuefe was still ongoing.

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

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


From jcking at openjdk.org  Wed Feb  8 02:42:58 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 8 Feb 2023 02:42:58 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
Message-ID: <PlJhy24TwmCmTjKIYmvlxrtwCbKvXl94QF7FvG0ezeY=.b83289f5-05e9-4843-a976-1fbe2abd2113@github.com>

On Tue, 7 Feb 2023 15:40:34 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to JDK
>   
>   Signed-off-by: Justin King <jcking at google.com>

I did integrate assuming somebody from Hotspot would sponsor. Does the bot/tooling not ensure reviews from applicable reviewers? If not, that seems non-ideal itself.

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

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


From dholmes at openjdk.org  Wed Feb  8 02:56:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Feb 2023 02:56:55 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
Message-ID: <lqI75bEbnx2schhc3uNXTUjfUC_a50QSgG2BZphMkrA=.cf4bef29-9055-4185-9b07-b00548d03510@github.com>

On Tue, 7 Feb 2023 15:40:34 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to JDK
>   
>   Signed-off-by: Justin King <jcking at google.com>

The bot can only check the required number of Reviewers (strictly 1 per OpenJDK rules but changeable as here via `/reviewers` command) but it doesn't know about the informal rules such as having reviewers from each affected area (there is no mapping from people to areas).

Regardless until your conversation with @tstuefe was complete this was not ready for integration.

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

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


From jcking at openjdk.org  Wed Feb  8 03:14:54 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 8 Feb 2023 03:14:54 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <lqI75bEbnx2schhc3uNXTUjfUC_a50QSgG2BZphMkrA=.cf4bef29-9055-4185-9b07-b00548d03510@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
 <lqI75bEbnx2schhc3uNXTUjfUC_a50QSgG2BZphMkrA=.cf4bef29-9055-4185-9b07-b00548d03510@github.com>
Message-ID: <3KMh7CoSK-qyddwQgjcQAubNFT_ThIZ3lSy-hW-0oTE=.ece75ba9-8bc6-427c-83bf-e1d7bf95fe0e@github.com>

On Wed, 8 Feb 2023 02:53:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The bot can only check the required number of Reviewers (strictly 1 per OpenJDK rules but changeable as here via `/reviewers` command) but it doesn't know about the informal rules such as having reviewers from each affected area (there is no mapping from people to areas).
> 
> Regardless until your conversation with @tstuefe was complete this was not ready for integration.

>From my point of view it was more questions to clarify how it worked at this point to get to an understanding, rather than specific objections, since the flags were no longer there. Requiring contributors to adhere to informal rules such as who can and cannot approve, and who you should and do not have to wait for, is not ideal. It relies heavily in determining who is part of what group and what group they are reviewing for. Wouldn't it make more sense to tie approval to labels and have reviewers explicitly approve via a command? Or allow reviewers to explicitly require their approval via a command? That way there is no guessing?
It would at least make it explicit and avoid miscommunication. The reviewers themselves are in the best position to know and bump required reviewers, not contributors.

Just my two cents.

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

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


From stuefe at openjdk.org  Wed Feb  8 06:49:59 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 8 Feb 2023 06:49:59 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <3KMh7CoSK-qyddwQgjcQAubNFT_ThIZ3lSy-hW-0oTE=.ece75ba9-8bc6-427c-83bf-e1d7bf95fe0e@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
 <lqI75bEbnx2schhc3uNXTUjfUC_a50QSgG2BZphMkrA=.cf4bef29-9055-4185-9b07-b00548d03510@github.com>
 <3KMh7CoSK-qyddwQgjcQAubNFT_ThIZ3lSy-hW-0oTE=.ece75ba9-8bc6-427c-83bf-e1d7bf95fe0e@github.com>
Message-ID: <EqbhdgRCx7MLHjNKeSpFGxw3pJHeMVMYY36irRL5ZVo=.070f7699-9046-47a9-9fbd-0f4833046495@github.com>

On Wed, 8 Feb 2023 03:11:32 GMT, Justin King <jcking at openjdk.org> wrote:

> > The bot can only check the required number of Reviewers (strictly 1 per OpenJDK rules but changeable as here via `/reviewers` command) but it doesn't know about the informal rules such as having reviewers from each affected area (there is no mapping from people to areas).
> > Regardless until your conversation with @tstuefe was complete this was not ready for integration.

Yep, that was a bit quick. But misunderstandings happen.

> 
> From my point of view it was more questions to clarify how it worked at this point to get to an understanding, rather than specific objections, since the flags were no longer there.

Hi Justin,

No, the discussion was still ongoing.

The informal rule is that ongoing discussions should be closed and that nobody strongly objects to a change. Two reviewers are easy to come by. The point of this rule is that you have a reasonable chance to block changes you strongly oppose. And that every change in the code base has the buy-in from the majority. 

Note that a patch is seldom blocked by one person alone for a prolonged amount of time. But sometimes, overworked reviewers may block-then-ghost without meaning to. Requires patience from authors and responsibility from reviewers. As an author, it is okay to ping after a while and, getting no answer, to integrate with a clear warning. 

This all requires more time than faster paced projects, which is accepted for most RFEs. Requires more discussion and convincing, but gives us a better community. Still faster than getting in kernel patches :)

> Requiring contributors to adhere to informal rules such as who can and cannot approve, and who you should and do not have to wait for, is not ideal. It relies heavily in determining who is part of what group and what group they are reviewing for. 

The rule is simply to resolve all discussions and opposition.

In fact, even if you are an unknown, come from the outside, and oppose a patch with good reasons, people will usually listen. If the points made were good, the author has to address those concerns (or, should).

> Wouldn't it make more sense to tie approval to labels and have reviewers explicitly approve via a command? Or allow reviewers to explicitly require their approval via a command? That way there is no guessing? It would at least make it explicit and avoid miscommunication. The reviewers themselves are in the best position to know and bump required reviewers, not contributors.

Our rules come from pre-Github times, where discussions happened on MLs. We may adapt over time. But you cannot codify all interactions into software-enforced rules, there is always a human element.

(I will continue the technical discussion separately)

Cheers, Thomas

> 
> Just my two cents.

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

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


From stuefe at openjdk.org  Wed Feb  8 07:01:54 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 8 Feb 2023 07:01:54 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
Message-ID: <CqcRlJQTNka8QBckR1rPIWRYDeLHSASL65TXlrwvXWA=.136167d9-3f67-4602-890b-96364e9d9d86@github.com>

On Tue, 7 Feb 2023 15:40:34 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to JDK
>   
>   Signed-off-by: Justin King <jcking at google.com>

I read through your explanation, and through the [design docs](https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizerDesignDocument), but my question remains unanswered. See below.

> > Metaspace objects hold pointers to malloced memory. Metaspace Objects can leak, that's accepted. So these pointers would leak too. Would that not give us tons of false positives?
> 
> No. LSan only cares that it can find pointers to malloc'ed memory, not that it can find pointers to Metaspace objects. The Metaspace is registered as a root region. It does however take into account ASan poisoning, which we added earlier to Metaspace. LSan will not scan poisoned memory regions that are part of root regions. We only poison in Metaspace when deallocation occurs and unpoison when allocation occurs.

But they are not poisened.

Upon JVM end, the heap still exists, holding class loaders, which hold references to CLDs. Those hold metaspace arenas (living in Metaspace), which hold Metaspace chunks, which are registered LSAN root areas, which hold C-allocated sub structures. These chunks are not poisened since they have never been returned to the chunk pool. They are still alive.

To put it in other words: even I as a human cannot determine that this is not a C-heap leak. Technically, it is. But it is accepted since we accept these things leaking. Since we don't support unloading and re-loading the JVM, we accept that to have a faster shutdown.

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

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


From asotona at openjdk.org  Wed Feb  8 07:23:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 07:23:49 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
Message-ID: <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>

On Tue, 7 Feb 2023 15:47:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)
>
>> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)
> 
> The production is the same as the one I quoted, but thanks for pointing me at the correct one. So:
> 
> 
> JavaTypeSignature:
>    ReferenceTypeSignature
>    BaseType 
> 
> 
> and
> 
> 
> ReferenceTypeSignature:
>    ClassTypeSignature
>    TypeVariableSignature
>    ArrayTypeSignature
> 
> 
> So, while I can expect that `ArrayTypeSignature` *is a* `Signature` (or `JavaTypeSignature`), I cannot explain why `ThrowsSignature` extends `Signature`. That doesn't seem to follow from the production. That is, if a client obtains a `Signature` and wanted to pattern match, what are the cases it should worry about? I believe the cases are the ones listed above.
> 
> One thing I missed is that e.g. `TypeParam` is *not* a signature (which is the only case among the nested classes in `Signature`). But `ThrowsSignature`, `TypeArg` and `TypeParam` are signatures even though that doesn't seem to be the case when looking at the production in the JVMS. If we want to keep these fine, but I don't think they should extend `Signature`, either directly or indirectly. That is, `Signature` should be a sealed type with 4 leaves (base-type/array/type var/class-type).

**Specification:**

MethodSignature:
[TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}

Result:
JavaTypeSignature 
VoidDescriptor

ThrowsSignature:
^ ClassTypeSignature 
^ TypeVariableSignature



**Reflect in API mapping:**

    public sealed interface ClassTypeSig
            extends RefTypeSig, ThrowableSig

and

    public sealed interface TypeVarSig
            extends RefTypeSig, ThrowableSig

and

    /**
     * @return method signature
     * @param typeParameters signatures for the type parameters
     * @param exceptions sigantures for the exceptions
     * @param result signature for the return type
     * @param arguments signatures for the method arguments
     */
    public static MethodSignature of(List<Signature.TypeParam> typeParameters,
                                     List<Signature.ThrowableSig> exceptions,
                                     Signature result,
                                     Signature... arguments) {


`Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `ClassTypeSig`.

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

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


From asotona at openjdk.org  Wed Feb  8 07:26:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 07:26:47 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
Message-ID: <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.1ae6dcde-eed4-406a-8ab4-84a1d1f6332b@github.com>

On Wed, 8 Feb 2023 07:21:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>>> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)
>> 
>> The production is the same as the one I quoted, but thanks for pointing me at the correct one. So:
>> 
>> 
>> JavaTypeSignature:
>>    ReferenceTypeSignature
>>    BaseType 
>> 
>> 
>> and
>> 
>> 
>> ReferenceTypeSignature:
>>    ClassTypeSignature
>>    TypeVariableSignature
>>    ArrayTypeSignature
>> 
>> 
>> So, while I can expect that `ArrayTypeSignature` *is a* `Signature` (or `JavaTypeSignature`), I cannot explain why `ThrowsSignature` extends `Signature`. That doesn't seem to follow from the production. That is, if a client obtains a `Signature` and wanted to pattern match, what are the cases it should worry about? I believe the cases are the ones listed above.
>> 
>> One thing I missed is that e.g. `TypeParam` is *not* a signature (which is the only case among the nested classes in `Signature`). But `ThrowsSignature`, `TypeArg` and `TypeParam` are signatures even though that doesn't seem to be the case when looking at the production in the JVMS. If we want to keep these fine, but I don't think they should extend `Signature`, either directly or indirectly. That is, `Signature` should be a sealed type with 4 leaves (base-type/array/type var/class-type).
>
> **Specification:**
> 
> MethodSignature:
> [TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}
> 
> Result:
> JavaTypeSignature 
> VoidDescriptor
> 
> ThrowsSignature:
> ^ ClassTypeSignature 
> ^ TypeVariableSignature
> 
> 
> 
> **Reflect in API mapping:**
> 
>     public sealed interface ClassTypeSig
>             extends RefTypeSig, ThrowableSig
> 
> and
> 
>     public sealed interface TypeVarSig
>             extends RefTypeSig, ThrowableSig
> 
> and
> 
>     /**
>      * @return method signature
>      * @param typeParameters signatures for the type parameters
>      * @param exceptions sigantures for the exceptions
>      * @param result signature for the return type
>      * @param arguments signatures for the method arguments
>      */
>     public static MethodSignature of(List<Signature.TypeParam> typeParameters,
>                                      List<Signature.ThrowableSig> exceptions,
>                                      Signature result,
>                                      Signature... arguments) {
> 
> 
> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `ClassTypeSig`.

`TypeParam` is not a signature, because it simply is not a signature.
Per spec:

TypeParameter:
Identifier ClassBound {InterfaceBound}

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

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


From asotona at openjdk.org  Wed Feb  8 07:27:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 07:27:48 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
Message-ID: <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>

On Wed, 8 Feb 2023 07:21:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>>> Class `Signature` (aka `JavaTypeSignature`), all subclasses, `MethodSignature` and `ClassSignature` are designed according to [JVMS 4.7.9.1 Signatures](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.7.9.1)
>> 
>> The production is the same as the one I quoted, but thanks for pointing me at the correct one. So:
>> 
>> 
>> JavaTypeSignature:
>>    ReferenceTypeSignature
>>    BaseType 
>> 
>> 
>> and
>> 
>> 
>> ReferenceTypeSignature:
>>    ClassTypeSignature
>>    TypeVariableSignature
>>    ArrayTypeSignature
>> 
>> 
>> So, while I can expect that `ArrayTypeSignature` *is a* `Signature` (or `JavaTypeSignature`), I cannot explain why `ThrowsSignature` extends `Signature`. That doesn't seem to follow from the production. That is, if a client obtains a `Signature` and wanted to pattern match, what are the cases it should worry about? I believe the cases are the ones listed above.
>> 
>> One thing I missed is that e.g. `TypeParam` is *not* a signature (which is the only case among the nested classes in `Signature`). But `ThrowsSignature`, `TypeArg` and `TypeParam` are signatures even though that doesn't seem to be the case when looking at the production in the JVMS. If we want to keep these fine, but I don't think they should extend `Signature`, either directly or indirectly. That is, `Signature` should be a sealed type with 4 leaves (base-type/array/type var/class-type).
>
> **Specification:**
> 
> MethodSignature:
> [TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}
> 
> Result:
> JavaTypeSignature 
> VoidDescriptor
> 
> ThrowsSignature:
> ^ ClassTypeSignature 
> ^ TypeVariableSignature
> 
> 
> 
> **Reflect in API mapping:**
> 
>     public sealed interface ClassTypeSig
>             extends RefTypeSig, ThrowableSig
> 
> and
> 
>     public sealed interface TypeVarSig
>             extends RefTypeSig, ThrowableSig
> 
> and
> 
>     /**
>      * @return method signature
>      * @param typeParameters signatures for the type parameters
>      * @param exceptions sigantures for the exceptions
>      * @param result signature for the return type
>      * @param arguments signatures for the method arguments
>      */
>     public static MethodSignature of(List<Signature.TypeParam> typeParameters,
>                                      List<Signature.ThrowableSig> exceptions,
>                                      Signature result,
>                                      Signature... arguments) {
> 
> 
> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.

`TypeParam` is not a signature, because it simply is not a signature.
Per spec:

TypeParameter:
Identifier ClassBound {InterfaceBound}

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

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


From asotona at openjdk.org  Wed Feb  8 07:33:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 07:33:53 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <XmkS1CfKIATrXGdgIqZNmfY4LI3R3wBuTj903AkwkR0=.3787d0f1-f617-426d-95ae-ac736abc43ed@github.com>

On Tue, 7 Feb 2023 15:20:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/CharacterRangeInfo.java line 146:
> 
>> 144:      * @param flags the range flags
>> 145:      */
>> 146:     static CharacterRangeInfo of(int startPc,
> 
> I get that the encoding is as per JaCoCo specification. However, I also wonder if the API should provide better accessors and or factories to let clients just reason about line/columns numbers. Or, maybe, provide static helpers to do the encoding/decoding.

Any reference to an official specification of CharacterRangeInfo is appreciated.
Thanks.

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

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


From asotona at openjdk.org  Wed Feb  8 08:13:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 08:13:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <qitIL4woheCXgtU3PEQiW2HgXeKxvsInBTYqJOSG3cY=.e28eda15-5eec-40e5-81c1-21c3b7b23ac4@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <iJyGP0x-bzXtRchGky3D7nJr-J2k4XPtl64FjcXJtCQ=.a9d4c1cd-08a7-4b8b-b43e-57a264d7265c@github.com>
 <qitIL4woheCXgtU3PEQiW2HgXeKxvsInBTYqJOSG3cY=.e28eda15-5eec-40e5-81c1-21c3b7b23ac4@github.com>
Message-ID: <i1dqvKVO0JLyBTVg_Rc7Pv6VyjHRwXUeY_V3LO6XQmA=.e041677f-6011-4205-86c6-f91efd1a7598@github.com>

On Tue, 7 Feb 2023 11:53:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `BootstrapMethodEntry` is not a constant pool entry, but `BootstrapMethodsAttribute` entry.
>> It might be rather moved under `attribute` package and renamed to `BootstrapMethodInfo` to follow the same pattern as other attributes/infos.
>
> I know it's part of an attribute - but reading the javadoc:
> 
> /**
>  * Models an entry in the bootstrap method table.  The bootstrap method table
>  * is stored in the {@code BootstrapMethods} attribute, but is modeled by
>  * the {@link ConstantPool}, since the bootstrap method table is logically
>  * part of the constant pool.
>  */
>  ```
>  
>  And also, seeing the method:
>  
>  ```
>  /**
>      * {@return the constant pool associated with this entry}
>      */
>     ConstantPool constantPool();
> 
> 
> It seems like the API is doing the (justifiable) trick of making BSMs look like if they are first-class CP entries (even if not specified that way in the JVMLS). I think that's a fine move, but if we go down that path we should be honest, and put this class in constantpool. At least this is my 0.02$.

I see your point. The duality of `BootstrapMethodEntry` and potential confusion when moved under `attribute` or under `constantpool` package is the reason why it probably should stay where it is.
However feel free to discuss it at the mailing list.
Thanks.

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

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


From asotona at openjdk.org  Wed Feb  8 08:20:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 08:20:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
Message-ID: <5QI6iG-7drs8x5fRc_0seFFHcfmOvYvkZCEMKaVN8Zw=.ebcb480c-019d-4339-af32-6759198aacac@github.com>

On Fri, 3 Feb 2023 18:33:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Classfile API moved under jdk.internal.classfile package
>
> src/java.base/share/classes/jdk/internal/classfile/FieldTransform.java line 92:
> 
>> 90:      * @return the field transform
>> 91:      */
>> 92:     static FieldTransform dropping(Predicate<FieldElement> filter) {
> 
> Could this be a more general static generic method on ClassfileTransform? (but I see CodeTransform doesn't have it - not sure if that's deliberate).

It is deliberate as we didn't found meaningful use case for transformation just dropping individual code elements.

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

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


From asotona at openjdk.org  Wed Feb  8 08:20:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 08:20:59 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <5dkNbhPrs6OGfgCDFzyB-KljRx8eT_UTqQfAIPNJy7w=.b950570a-4d5e-45fa-901d-95cc2b1560fc@github.com>

On Tue, 7 Feb 2023 15:18:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/CharacterRangeInfo.java line 80:
> 
>> 78:      * well as increment and decrement expressions (both prefix and postfix).
>> 79:      * <li>{@link jdk.internal.classfile.Classfile#CRT_FLOW_CONTROLLER} An expression
>> 80:      * whose value will effect control flow. Flowcon in the following:
> 
> This sentence seems hard to parse. If `Flowcon` is the name of an expression in pseudocode, perhaps using `{@code}` would help.

Will fix it, thanks.

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

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


From asotona at openjdk.org  Wed Feb  8 09:00:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 09:00:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <pU5kuRB02JMpu4LGjx9lFi4tpXaUOL8s9y2r-kqDb9Q=.bb0f46e8-1aec-436f-9b0a-0542ef1b55a9@github.com>

On Tue, 7 Feb 2023 15:26:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/CodeAttribute.java line 52:
> 
>> 50:     byte[] codeArray();
>> 51: 
>> 52:     int labelToBci(Label label);
> 
> Missing javadoc here. (also, this method looks a bit odd in here - but I see uses e.g. in ClassPrinterImpl)

Will fix it, thanks.

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

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


From asotona at openjdk.org  Wed Feb  8 10:40:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 10:40:34 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v14]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <UGEwpYPu7X9LadwlqPvS8FvvVngcwlBLjZE7j4iMxcQ=.fdc3b944-a490-43ba-b577-4ccbb2de41f7@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  javadoc fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/1aabe0e3..df08b351

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

  Stats: 62 lines in 42 files changed: 11 ins; 1 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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


From asotona at openjdk.org  Wed Feb  8 10:40:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 10:40:39 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <Yc73e5S4wD8hzguB0T7UQwGVEqofdiqguOlFAiSeBZE=.4e361b28-8a11-4dce-aa00-4e36d76802d8@github.com>

On Tue, 7 Feb 2023 15:59:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/ModuleAttribute.java line 132:
> 
>> 130:     }
>> 131: 
>> 132:     static ModuleAttribute of(ModuleDesc moduleName,
> 
> Some missing javadoc in this class

Will fix it, thanks.

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

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


From asotona at openjdk.org  Wed Feb  8 11:03:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 11:03:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <p6l3I5tXbZ_TXPOqxMZatAOfGzzO3ym2zxFafKkKVDM=.dbf87106-bd11-4cc3-8ca9-9e6b8def0f6a@github.com>

On Tue, 7 Feb 2023 16:09:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/StackMapTableAttribute.java line 68:
> 
>> 66:      * A simple stack value.
>> 67:      */
>> 68:     public enum SimpleVerificationTypeInfo implements VerificationTypeInfo {
> 
> I note that in this class we have made the decision to model all the innards (XYZInfo) as nested classes - while in all the other cases XYZInfo are toplevel types. Moving forward, we should pick something consistent.

Every case has been considered individually, evaluated on use cases and pros and cons have been weighted. Unified approach across the whole API would be nice, however not so simple and not the highest priority.

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

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


From mcimadamore at openjdk.org  Wed Feb  8 11:09:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Feb 2023 11:09:53 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
Message-ID: <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>

On Wed, 8 Feb 2023 07:24:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> **Specification:**
>> 
>> MethodSignature:
>> [TypeParameters] ( {JavaTypeSignature} ) Result {ThrowsSignature}
>> 
>> Result:
>> JavaTypeSignature 
>> VoidDescriptor
>> 
>> ThrowsSignature:
>> ^ ClassTypeSignature 
>> ^ TypeVariableSignature
>> 
>> 
>> 
>> **Reflect in API mapping:**
>> 
>>     public sealed interface ClassTypeSig
>>             extends RefTypeSig, ThrowableSig
>> 
>> and
>> 
>>     public sealed interface TypeVarSig
>>             extends RefTypeSig, ThrowableSig
>> 
>> and
>> 
>>     /**
>>      * @return method signature
>>      * @param typeParameters signatures for the type parameters
>>      * @param exceptions sigantures for the exceptions
>>      * @param result signature for the return type
>>      * @param arguments signatures for the method arguments
>>      */
>>     public static MethodSignature of(List<Signature.TypeParam> typeParameters,
>>                                      List<Signature.ThrowableSig> exceptions,
>>                                      Signature result,
>>                                      Signature... arguments) {
>> 
>> 
>> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.
>
> `TypeParam` is not a signature, because it simply is not a signature.
> Per spec:
> 
> TypeParameter:
> Identifier ClassBound {InterfaceBound}

> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.

I really don't follow here. ThrowableSig is a piece of a method signature, which starts with "^" and is followed by either a class or a typevar signature. You can never encounter it from the toplevel JavaTypeSignature production. It's ok (as I have said) to have a ThrowableSig element in the API to model the production, but that element should not be a subtype of Signature (at least not if Signature, as you claimed is meant to model the JavaTypeSignature production). That is, there's no "is a" relationship between JavaTypeSignature and ThrowableSig (at least not that I can see when looking at the productions).

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

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


From asotona at openjdk.org  Wed Feb  8 11:09:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 11:09:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <ubqEqa6BH65hdOBcovhGQACL7JtzTepvG57XeC7z0K4=.045606e5-9421-4d8f-8e7f-e6bd9f529e98@github.com>

On Tue, 7 Feb 2023 16:07:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/NestMembersAttribute.java line 72:
> 
>> 70:      * @param nestMembers the member classes of the nest
>> 71:      */
>> 72:     static NestMembersAttribute ofSymbols(List<ClassDesc> nestMembers) {
> 
> I see that in some classes we use the `Symbols` prefix, in others we just use `of` - we should try to make the more consistent (in the future).

`ofSymbols` is an alternative to `of` when conflicting method parameters.
In such case `of` refers to CP entries and `ofSymbols` refer to independent symbols describing the objects, like for example `ClassDesc`, `MethodTypeDesc`, `PackageDesc`

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

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


From mcimadamore at openjdk.org  Wed Feb  8 11:18:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Feb 2023 11:18:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <ubqEqa6BH65hdOBcovhGQACL7JtzTepvG57XeC7z0K4=.045606e5-9421-4d8f-8e7f-e6bd9f529e98@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
 <ubqEqa6BH65hdOBcovhGQACL7JtzTepvG57XeC7z0K4=.045606e5-9421-4d8f-8e7f-e6bd9f529e98@github.com>
Message-ID: <Jk3w1_xkaBE7C1tt8-1rH4svfdjuyIM3OsJDGQl9Pi4=.e93ed59e-c4a9-4566-aac2-79879bc66241@github.com>

On Wed, 8 Feb 2023 11:05:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `ofSymbols` is an alternative to `of` when conflicting method parameters. In such case `of` refers to CP entries and `ofSymbols` refer to independent symbols describing the objects, like for example `ClassDesc`, `MethodTypeDesc`, `PackageDesc`

Yes, I was noting that some classes e.g. ModuleProvideInfo do not seem to follow this logic:


static ModuleProvideInfo of(ClassEntry provides, ClassEntry... providesWith) { ... }

static ModuleProvideInfo of(ClassDesc provides, List<ClassDesc> providesWith) { ... }

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

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


From mcimadamore at openjdk.org  Wed Feb  8 11:22:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Feb 2023 11:22:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <XmkS1CfKIATrXGdgIqZNmfY4LI3R3wBuTj903AkwkR0=.3787d0f1-f617-426d-95ae-ac736abc43ed@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
 <XmkS1CfKIATrXGdgIqZNmfY4LI3R3wBuTj903AkwkR0=.3787d0f1-f617-426d-95ae-ac736abc43ed@github.com>
Message-ID: <Sxvu5MMpl41oP_h0CwnQ5y6H1zVyB9JRx3Qiq502Jfg=.6c7d2e51-5361-4d4e-98a0-769bd4c5b548@github.com>

On Wed, 8 Feb 2023 07:31:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Any reference to an official specification of CharacterRangeInfo is appreciated. Thanks.

There's this - which points back to javac code :-)

https://github.com/jacoco/jacoco/wiki/CharacterRangeTable

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

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


From asotona at openjdk.org  Wed Feb  8 12:22:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 12:22:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
 <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
Message-ID: <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgWLV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>

On Wed, 8 Feb 2023 11:07:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `TypeParam` is not a signature, because it simply is not a signature.
>> Per spec:
>> 
>> TypeParameter:
>> Identifier ClassBound {InterfaceBound}
>
>> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.
> 
> I really don't follow here. ThrowableSig is a piece of a method signature, which starts with "^" and is followed by either a class or a typevar signature. You can never encounter it from the toplevel JavaTypeSignature production. It's ok (as I have said) to have a ThrowableSig element in the API to model the production, but that element should not be a subtype of Signature (at least not if Signature, as you claimed is meant to model the JavaTypeSignature production). That is, there's no "is a" relationship between JavaTypeSignature and ThrowableSig (at least not that I can see when looking at the productions).

OK, I see your point now, I'll fix it.
Thanks

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

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


From ihse at openjdk.org  Wed Feb  8 13:39:58 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 8 Feb 2023 13:39:58 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
Message-ID: <CQDe7qMOvOVHHulN002h0ic9aSVEnkpb5Z_DZY8lE3w=.33923095-d05e-43fe-84b0-a11149bea67a@github.com>

On Tue, 7 Feb 2023 15:40:34 GMT, Justin King <jcking at openjdk.org> wrote:

>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that also fail with ASan, which is being looked at separately. It is especially useful when combined with ASan, as LSan can use poisoning information to determine what memory to scan or not to scan, making leak detection more accurate and faster.
>> 
>> **Suppressing:**
>> Currently the suppression list is only used to suppress JLI leaks that are known, the rest are done in code. Suppressing needs to identify the source of thet leak. Due to Hotspot's code organization, we would need to suppress `os::malloc` and friends, which would suppress everything. Suppressing in code has the added benefit of being explicit and surviving refactors if methods change.
>> 
>> **Caveats:**
>> - By default ASan enables LSan, however we explicitly disable it unless `--enable-lsan` is given. It is useful to be able to use ASan without LSan. Using LSan by itself is less likely to be useful and will probably not work, but its still possible currently.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to JDK
>   
>   Signed-off-by: Justin King <jcking at google.com>

I apologize, the fault lies entirely with me. Justin should have no blame in this -- he is not a committer and is not expected to fully know all rules for integration. That responsibility lies with the sponsor, in this case, me.

I read @dholmes-ora's comment:
> Updates look good - glad to see the flag changes go away!

> I suggest factoring out the change to test/jdk/jni/nullCaller/exeNullCallerTest.cpp as it is a JDK test and not part of hotspot. Thanks.

as an approval from Hotspot, given that the JDK test was removed, which a later commit did indeed remove. And, like Justin, I interpreted Thomas comments as questions that were now answered, rather than an ongoing discussion about the 

I did not realize there were still an ongoing discussion, and was too eager to sponsor this PR.

@tstuefe @dholmes-ora Do you want me to revert this change? Or should we continue the discussion in a follow-up bug that can address the remaining problems?

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

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


From asotona at openjdk.org  Wed Feb  8 13:47:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 8 Feb 2023 13:47:59 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgWLV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
 <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
 <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgW
 LV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>
Message-ID: <wzHOP5Fnj3FhcNs61TKxxBZ5R6fB-oky72z_hlf1Svk=.ed56a42f-cce6-415a-b93a-d39dee6adc78@github.com>

On Wed, 8 Feb 2023 12:19:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>>> `Signature.ThrowableSig` is a `Signature` and it is a common super of `ClassTypeSig` and `TypeVarSig`.
>> 
>> I really don't follow here. ThrowableSig is a piece of a method signature, which starts with "^" and is followed by either a class or a typevar signature. You can never encounter it from the toplevel JavaTypeSignature production. It's ok (as I have said) to have a ThrowableSig element in the API to model the production, but that element should not be a subtype of Signature (at least not if Signature, as you claimed is meant to model the JavaTypeSignature production). That is, there's no "is a" relationship between JavaTypeSignature and ThrowableSig (at least not that I can see when looking at the productions).
>
> OK, I see your point now, I'll fix it.
> Thanks

During the fix I found the definition that `ThrowableSig` (as a super-set of `ClassTypeSig` and `TypeVarSig`) IS `Signature` - that fact is critical for processing.
For example when `MethodSignature` is serialized `ThrowableSig::signatureString` is critical.
Or `ClassRemapper` depends on the inheritence:

signature.throwableSignatures().stream().map(this::mapSignature).toList()

however `mapSignature` could not be applied on `ThrowableSig` when it does not inherit from `Signature`.

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

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


From ihse at openjdk.org  Wed Feb  8 13:51:43 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 8 Feb 2023 13:51:43 GMT
Subject: RFR: 8301753: AppendFile needs to add a new line to be compatible
 with old make
In-Reply-To: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
References: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
Message-ID: <1K63mCE0-5fmbNIZDWixdTHjjvLF3qRAEzKax4J9MRs=.54f7f84a-4f90-4d44-96b2-b581a03f1fa0@github.com>

On Tue, 7 Feb 2023 20:56:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The newline is added to be compatible with old make 3.81 which is still used on MacOSX.
> Fixed actually by dnsimon.

I don't think this fix is correct. Look again at the documentation of make 4+ `$(file)` command:

"When writing files, text will be written to the file. If text does not already end in a newline a final newline will be written (even if text is the empty string)."

That is not what this patch is doing. It is unconditionally appending a newline to the string.

It might be the case that all places that we currently call this function lack a trailing newline, and if so, this fix is going to "work". But if not, it is going to create an additional empty line. 

And even it it would happen to "work" for all our current code, the behavior would still not be the same as for make 4+, so any future calls might break.

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

Changes requested by ihse (Reviewer).

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


From ihse at openjdk.org  Wed Feb  8 13:55:44 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 8 Feb 2023 13:55:44 GMT
Subject: RFR: 8301753: AppendFile needs to add a new line to be compatible
 with old make
In-Reply-To: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
References: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
Message-ID: <N2RuGIt9PM6QRtjzRPfhb7035e_fwPlmJMM1PuwNySw=.80e44827-8c22-4f87-86c2-2b456a17da50@github.com>

On Tue, 7 Feb 2023 20:56:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The newline is added to be compatible with old make 3.81 which is still used on MacOSX.
> Fixed actually by dnsimon.

Possible solutions include:
* Stripping any potential newline from the end of the input, and keep unconditionally adding one in the printf statement like in the current patch.
* Checking if the input ends with a newline, and print the additional `\n` only if it doesn't.
* Change the requirements for both the make 4+ and printf version to never have input ending in a newline. This would likely have to be verified by an assert.

My personal recommendation would be to pick the first solution on this list, I think it is easiest to implement in Make.

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

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


From erikj at openjdk.org  Wed Feb  8 14:19:44 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 8 Feb 2023 14:19:44 GMT
Subject: RFR: 8301753: AppendFile needs to add a new line to be compatible
 with old make
In-Reply-To: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
References: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
Message-ID: <t935tSZ0QU_1L06ybi9fdoAzK-R0PFv0ijckfmQauNU=.1ef2e813-a6aa-483c-883c-fece632759a0@github.com>

On Tue, 7 Feb 2023 20:56:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The newline is added to be compatible with old make 3.81 which is still used on MacOSX.
> Fixed actually by dnsimon.

It looks like you are correct Magnus, I didn't think about that. I will see what I can do about solving this properly.

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

Changes requested by erikj (Reviewer).

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


From ihse at openjdk.org  Wed Feb  8 14:24:43 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 8 Feb 2023 14:24:43 GMT
Subject: RFR: 8301753: AppendFile needs to add a new line to be compatible
 with old make
In-Reply-To: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
References: <08ih3Io1PSLTjSHddK1st9xjI86wVIU0a13sI6CBj3s=.1ec5877a-fa1c-4bf0-8aac-83d951b34e8b@github.com>
Message-ID: <mYWkgh3GMwL_w5kwM71PEJF2DFFaQtmY4dyYr-A5jwA=.44a8eee4-5082-439c-b8b3-cb323bf6c8f9@github.com>

On Tue, 7 Feb 2023 20:56:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The newline is added to be compatible with old make 3.81 which is still used on MacOSX.
> Fixed actually by dnsimon.

@lmesnik If you want, I can take over the issue and solve it correctly. Let me know.

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

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


From jcking at openjdk.org  Wed Feb  8 15:32:01 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 8 Feb 2023 15:32:01 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <EqbhdgRCx7MLHjNKeSpFGxw3pJHeMVMYY36irRL5ZVo=.070f7699-9046-47a9-9fbd-0f4833046495@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
 <lqI75bEbnx2schhc3uNXTUjfUC_a50QSgG2BZphMkrA=.cf4bef29-9055-4185-9b07-b00548d03510@github.com>
 <3KMh7CoSK-qyddwQgjcQAubNFT_ThIZ3lSy-hW-0oTE=.ece75ba9-8bc6-427c-83bf-e1d7bf95fe0e@github.com>
 <EqbhdgRCx7MLHjNKeSpFGxw3pJHeMVMYY36irRL5ZVo=.070f7699-9046-47a9-9fbd-0f4833046495@github.com>
Message-ID: <hB0FR6qDcpuhdOsR-_8sl8lopoK7QE4Si50Pl7pWzSA=.5e16542c-85de-4465-9a0a-0a50b58ae9a4@github.com>

On Wed, 8 Feb 2023 06:45:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The informal rule is that ongoing discussions should be closed and that nobody strongly objects to a change. Two reviewers are easy to come by. The point of this rule is that you have a reasonable chance to block changes you strongly oppose. And that every change in the code base has the buy-in from the majority.
> 
> Note that a patch is seldom blocked by one person alone for a prolonged amount of time. But sometimes, overworked reviewers may block-then-ghost without meaning to. Requires patience from authors and responsibility from reviewers. As an author, it is okay to ping after a while and, getting no answer, to integrate with a clear warning.
> 
> This all requires more time than faster paced projects, which is accepted for most RFEs. Requires more discussion and convincing, but gives us a better community. Still faster than getting in kernel patches :)

Okay, fair. I will keep all this in mind. Thank you! Let's continue the discussion, will respond in a second.

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

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


From jcking at openjdk.org  Wed Feb  8 15:41:57 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 8 Feb 2023 15:41:57 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <CqcRlJQTNka8QBckR1rPIWRYDeLHSASL65TXlrwvXWA=.136167d9-3f67-4602-890b-96364e9d9d86@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
 <CqcRlJQTNka8QBckR1rPIWRYDeLHSASL65TXlrwvXWA=.136167d9-3f67-4602-890b-96364e9d9d86@github.com>
Message-ID: <PfZrLjrGOg-9cRUZG9_D4i0AYZ97DjlkZTtoT6HxipM=.29137eab-907d-47d1-9fbc-12d3ffc06d64@github.com>

On Wed, 8 Feb 2023 06:58:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I read through your explanation, and through the [design docs](https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizerDesignDocument), but my question remains unanswered. See below.
> 
> > > Metaspace objects hold pointers to malloced memory. Metaspace Objects can leak, that's accepted. So these pointers would leak too. Would that not give us tons of false positives?
> > 
> > 
> > No. LSan only cares that it can find pointers to malloc'ed memory, not that it can find pointers to Metaspace objects. The Metaspace is registered as a root region. It does however take into account ASan poisoning, which we added earlier to Metaspace. LSan will not scan poisoned memory regions that are part of root regions. We only poison in Metaspace when deallocation occurs and unpoison when allocation occurs.
> 
> But they are not poisened.
> 
> Upon JVM end, the heap still exists, holding class loaders, which hold references to CLDs. Those hold metaspace arenas (living in Metaspace), which hold Metaspace chunks, which are registered LSAN root areas, which hold C-allocated sub structures. These chunks are not poisened since they have never been returned to the chunk pool. They are still alive.
> 
> To put it in other words: even I as a human cannot determine that this is not a C-heap leak. Technically, it is. But it is accepted since we accept these things leaking. Since we don't support unloading and re-loading the JVM, we accept that to have a faster shutdown.

Let's ignore ASan/poisoning for now, its an optimization. I shouldn't have brought it up.

LSan leak checking, as implemented for Hotspot, happens before the JVM has actually shutdown. It happens immediately after one thread wins the right to begin shutting down and other threads are either waiting or doing other work. Everything is still alive, including CollectedHeap, Metaspace, and CodeHeap. We ignore leaks as a result of shutdown this way, because as you mentioned we are not that concerned. Outside of Hotspot, LSan leak checking is typically done at program exit. If you do that with Hotspot you will definitely get false positives.

Note: If you want, feel free to run a build with `--enable-asan` and `--enable-lsan` and run some of the test tiers. Some tests will fail due to some existing incompatibilities with ASan (working on fixing those separately), but some will fail with real leaks. I need to report these, just have not gotten around to it yet. Plan was to do so after this integrated. Most of the remaining ones are minor.

The only time false positives can happen is some of the tests which do some interesting things and use a custom launcher, these don't inherit our options and will attempt to leak check at exit. I am slowly going through and correcting these. They should be rare at this point.

On a side note, once this discussion is complete and in favor of this change, I should probably add some documentation related to sanitizers in Hotspot including ASan, LSan, and UBSan.

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

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


From erikj at openjdk.org  Wed Feb  8 21:55:53 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 8 Feb 2023 21:55:53 GMT
Subject: Integrated: 8301717: Remove obsolete jib profiles
In-Reply-To: <i0JMNwIGtf8qJQKmF4nqcFymwB0VbowdePt3zRKiQow=.03dfde57-c188-4f6d-92dd-aa78d9a0cb32@github.com>
References: <i0JMNwIGtf8qJQKmF4nqcFymwB0VbowdePt3zRKiQow=.03dfde57-c188-4f6d-92dd-aa78d9a0cb32@github.com>
Message-ID: <KwrsnjRSho5xopDjUGmyuMxnGt_4MFdyDQwaoDSQiRk=.31260ea2-9e66-49d9-90a1-0004cd52cbe7@github.com>

On Thu, 2 Feb 2023 22:44:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This patch removes some now obsolete jib profiles configurations.

This pull request has now been integrated.

Changeset: 8a9e383d
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a9e383dba58ed047ca46007b5af186aade05b59
Stats:     18 lines in 1 file changed: 0 ins; 18 del; 0 mod

8301717: Remove obsolete jib profiles

Reviewed-by: dholmes, ihse

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

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


From christoph.langer at sap.com  Wed Feb  8 22:00:46 2023
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 8 Feb 2023 22:00:46 +0000
Subject: JDK-8302000: jdk11u build has a very subtle race condition
 causing builds to break.
In-Reply-To: <IA1PR05MB8971BFDB93530CB78555C43DB5DB9@IA1PR05MB8971.namprd05.prod.outlook.com>
References: <IA1PR05MB8971BFDB93530CB78555C43DB5DB9@IA1PR05MB8971.namprd05.prod.outlook.com>
Message-ID: <DB6PR0202MB269436BDC9BC402240BF91438AD89@DB6PR0202MB2694.eurprd02.prod.outlook.com>

Hi Kumar,

yes, I would agree. Option [3] is my preferred. It brings the code closer to upstream.

Thanks for tackling this.

Cheers
Christoph

From: build-dev <build-dev-retn at openjdk.org> On Behalf Of Kumar Srinivasan
Sent: Dienstag, 7. Februar 2023 20:20
To: build-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
Subject: JDK-8302000: jdk11u build has a very subtle race condition causing builds to break.

Hi build-team, updates-team,

We encountered a build issue since jdk 11.0.18, the root cause and possible solutions are
documented in JDK-8302000[1]. I am willing to make the change as noted in the bug.

Let me know if approach #2 or #3 is the best option, I would like
to get a consensus from the team to take the best approach.

Thanks
Kumar Srinivasan
[1] https://bugs.openjdk.org/browse/JDK-8302000

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230208/a579782b/attachment.htm>

From stuefe at openjdk.org  Thu Feb  9 06:35:57 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 9 Feb 2023 06:35:57 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <PfZrLjrGOg-9cRUZG9_D4i0AYZ97DjlkZTtoT6HxipM=.29137eab-907d-47d1-9fbc-12d3ffc06d64@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
 <CqcRlJQTNka8QBckR1rPIWRYDeLHSASL65TXlrwvXWA=.136167d9-3f67-4602-890b-96364e9d9d86@github.com>
 <PfZrLjrGOg-9cRUZG9_D4i0AYZ97DjlkZTtoT6HxipM=.29137eab-907d-47d1-9fbc-12d3ffc06d64@github.com>
Message-ID: <KgZVWLUg8GoK_kJXkP_4wUx1Zyle1DcJXA1HlJQRQJA=.874b57e5-6666-4a7b-bfa5-e3096ab0e304@github.com>

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

> > I read through your explanation, and through the [design docs](https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizerDesignDocument), but my question remains unanswered. See below.
> > > > Metaspace objects hold pointers to malloced memory. Metaspace Objects can leak, that's accepted. So these pointers would leak too. Would that not give us tons of false positives?
> > > 
> > > 
> > > No. LSan only cares that it can find pointers to malloc'ed memory, not that it can find pointers to Metaspace objects. The Metaspace is registered as a root region. It does however take into account ASan poisoning, which we added earlier to Metaspace. LSan will not scan poisoned memory regions that are part of root regions. We only poison in Metaspace when deallocation occurs and unpoison when allocation occurs.
> > 
> > 
> > But they are not poisened.
> > Upon JVM end, the heap still exists, holding class loaders, which hold references to CLDs. Those hold metaspace arenas (living in Metaspace), which hold Metaspace chunks, which are registered LSAN root areas, which hold C-allocated sub structures. These chunks are not poisened since they have never been returned to the chunk pool. They are still alive.
> > To put it in other words: even I as a human cannot determine that this is not a C-heap leak. Technically, it is. But it is accepted since we accept these things leaking. Since we don't support unloading and re-loading the JVM, we accept that to have a faster shutdown.
> 
> Let's ignore ASan/poisoning for now, its an optimization. I shouldn't have brought it up.
> 
> LSan leak checking, as implemented for Hotspot, happens before the JVM has actually shutdown. It happens immediately after one thread wins the right to begin shutting down and other threads are either waiting or doing other work. Everything is still alive, including CollectedHeap, Metaspace, and CodeHeap. We ignore leaks as a result of shutdown this way, because as you mentioned we are not that concerned. Outside of Hotspot, LSan leak checking is typically done at program exit. If you do that with Hotspot you will definitely get false positives.
> 
> Note: If you want, feel free to run a build with `--enable-asan` and `--enable-lsan` and run some of the test tiers. Some tests will fail due to some existing incompatibilities with ASan (working on fixing those separately), but some will fail with real leaks. I need to report these, just have not gotten around to it yet. Plan was to do so after this integrated. Most of the remaining ones are minor.
> 
> The only time false positives can happen is some of the tests which do some interesting things and use a custom launcher, these don't inherit our options and will attempt to leak check at exit. I am slowly going through and correcting these. They should be rare at this point.
> 
> On a side note, once this discussion is complete and in favor of this change, I should probably add some documentation related to sanitizers in Hotspot including ASan, LSan, and UBSan.

Thanks for the explanation, @jcking . I'm out of time for this one, but since this PR is already integrated, you don't need my immediate feedback. I'll play around with LSAN when I have time. Finding leaked C-heap substructures from dead metaspace objects should certainly be useful.

Cheers, Thomas

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

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


From ysuenaga at openjdk.org  Thu Feb  9 06:49:52 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 9 Feb 2023 06:49:52 GMT
Subject: RFR: 8301855: C4819 warnings were reported in harfbuzz on Windows
In-Reply-To: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
References: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
Message-ID: <45OH0CS2Bn_Rg6AP_HCaZpJTnxUXV90H3yRQAwKNPK4=.aeac99b4-9216-4dbf-8b63-d0238c768b3e@github.com>

On Mon, 6 Feb 2023 12:35:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

This issue will be treated in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)

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

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


From ysuenaga at openjdk.org  Thu Feb  9 06:49:53 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 9 Feb 2023 06:49:53 GMT
Subject: Withdrawn: 8301855: C4819 warnings were reported in harfbuzz on
 Windows
In-Reply-To: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
References: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
Message-ID: <VtwSBI44mPS1foCHbqHo1HaM7vVW6rJVnLp8D0qL2kA=.4907c9d6-63f7-4dbf-8e05-7442fea638f3@github.com>

On Mon, 6 Feb 2023 12:35:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

This pull request has been closed without being integrated.

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

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


From ysuenaga at openjdk.org  Thu Feb  9 06:50:53 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 9 Feb 2023 06:50:53 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <jnDkh-pRd4AUSguXSVO0I0crrExfDd7HGSEYXf5OHmY=.ea9673bc-f65d-4d35-b5ed-fd4bc1977b7f@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

This issue will be treated in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)

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

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


From ysuenaga at openjdk.org  Thu Feb  9 06:50:53 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 9 Feb 2023 06:50:53 GMT
Subject: Withdrawn: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <673wm8gRq6UD5GruLDma1RejnQWQBytTzafsszGncE0=.21427eab-4192-4b23-9cc9-00fc9d950044@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

This pull request has been closed without being integrated.

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

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


From dholmes at openjdk.org  Thu Feb  9 07:23:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Feb 2023 07:23:58 GMT
Subject: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]
In-Reply-To: <CQDe7qMOvOVHHulN002h0ic9aSVEnkpb5Z_DZY8lE3w=.33923095-d05e-43fe-84b0-a11149bea67a@github.com>
References: <CyleK-s9KEthDBCb2kBeUyGBU8E8QUKLqkqKrDYBdPU=.59d2199d-a83d-44b2-b769-bd32f8ba342f@github.com>
 <IA44YM_2Jghoob7ahcnUnQNjaRTFHLToFQxLW-lomgc=.6dd017e8-d913-4baf-b83d-b002858f9fd8@github.com>
 <CQDe7qMOvOVHHulN002h0ic9aSVEnkpb5Z_DZY8lE3w=.33923095-d05e-43fe-84b0-a11149bea67a@github.com>
Message-ID: <HX44XqLjnE5sBWArwBRiCnKqfnh7eOloAQuFqQ8z0Eg=.5bb9d370-748c-4c19-bf8a-89e584357638@github.com>

On Wed, 8 Feb 2023 13:37:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to JDK
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> I apologize, the fault lies entirely with me. Justin should have no blame in this -- he is not a committer and is not expected to fully know all rules for integration. That responsibility lies with the sponsor, in this case, me.
> 
> I read @dholmes-ora's comment:
>> Updates look good - glad to see the flag changes go away!
> 
>> I suggest factoring out the change to test/jdk/jni/nullCaller/exeNullCallerTest.cpp as it is a JDK test and not part of hotspot. Thanks.
> 
> as an approval from Hotspot, given that the JDK test was removed, which a later commit did indeed remove. And, like Justin, I interpreted Thomas comments as questions that were now answered, rather than an ongoing discussion about the 
> 
> I did not realize there were still an ongoing discussion, and was too eager to sponsor this PR.
> 
> @tstuefe @dholmes-ora Do you want me to revert this change? Or should we continue the discussion in a follow-up bug that can address the remaining problems?

@magicus  no need to backout. Thanks.

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

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


From asotona at openjdk.org  Thu Feb  9 08:44:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 08:44:41 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  AttributeElement.Kind removal (#48)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/df08b351..753e6847

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

  Stats: 160 lines in 16 files changed: 0 ins; 89 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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


From asotona at openjdk.org  Thu Feb  9 08:48:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 08:48:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <Jk3w1_xkaBE7C1tt8-1rH4svfdjuyIM3OsJDGQl9Pi4=.e93ed59e-c4a9-4566-aac2-79879bc66241@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
 <ubqEqa6BH65hdOBcovhGQACL7JtzTepvG57XeC7z0K4=.045606e5-9421-4d8f-8e7f-e6bd9f529e98@github.com>
 <Jk3w1_xkaBE7C1tt8-1rH4svfdjuyIM3OsJDGQl9Pi4=.e93ed59e-c4a9-4566-aac2-79879bc66241@github.com>
Message-ID: <0l15xDaAOrY1jj8o_GdY6kJFNLVzUEEFy2Versfm9vc=.107f83d9-6f72-43a4-99bd-4762c37d268e@github.com>

On Wed, 8 Feb 2023 11:16:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> `ofSymbols` is an alternative to `of` when conflicting method parameters.
>> In such case `of` refers to CP entries and `ofSymbols` refer to independent symbols describing the objects, like for example `ClassDesc`, `MethodTypeDesc`, `PackageDesc`
>
>> `ofSymbols` is an alternative to `of` when conflicting method parameters. In such case `of` refers to CP entries and `ofSymbols` refer to independent symbols describing the objects, like for example `ClassDesc`, `MethodTypeDesc`, `PackageDesc`
> 
> Yes, I was noting that some classes e.g. ModuleProvideInfo do not seem to follow this logic:
> 
> 
> static ModuleProvideInfo of(ClassEntry provides, ClassEntry... providesWith) { ... }
> 
> static ModuleProvideInfo of(ClassDesc provides, List<ClassDesc> providesWith) { ... }

Yes, the alternate `ofSymbols` is used only when there is a conflict, which is not the case of `ModuleProvideInfo` factory methods, there is differentiating first argument.
In case of var-args vs Lists - that is another topic with long history of search for the right balance.

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

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


From mcimadamore at openjdk.org  Thu Feb  9 12:47:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Feb 2023 12:47:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <wzHOP5Fnj3FhcNs61TKxxBZ5R6fB-oky72z_hlf1Svk=.ed56a42f-cce6-415a-b93a-d39dee6adc78@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
 <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
 <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgW
 LV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>
 <wzHOP5Fnj3FhcNs61TKxxBZ5R6fB-oky72z_hlf1Svk=.ed56a42f-cce6-415a-b93a-d39dee6adc78@github.com>
Message-ID: <hhnDQ3Sx7BiJ05Jt32dwEKi93Rs1rkxi_kTbfJH93oI=.ace5a7f6-8ba4-42cc-9046-8ac190b12866@github.com>

On Wed, 8 Feb 2023 13:44:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> OK, I see your point now, I'll fix it.
>> Thanks
>
> During the fix I found the definition that `ThrowableSig` (as a super-set of `ClassTypeSig` and `TypeVarSig`) IS `Signature` - that fact is critical for processing.
> For example when `MethodSignature` is serialized `ThrowableSig::signatureString` is critical.
> Or `ClassRemapper` depends on the inheritence:
> 
> signature.throwableSignatures().stream().map(this::mapSignature).toList()
> 
> however `mapSignature` could not be applied on `ThrowableSig` when it does not inherit from `Signature`.

I think I also see where the current hierarchy comes from - e.g. while `ThrowableSig` is a part of a method signature, it is indeed used by the production to specify a set of signatures that belong to that set. Thanks for the patience.

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

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


From mcimadamore at openjdk.org  Thu Feb  9 14:15:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Feb 2023 14:15:09 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
Message-ID: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>

On Thu, 9 Feb 2023 08:44:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AttributeElement.Kind removal (#48)

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 66:

> 64:      * @param <V> the type of the optional value
> 65:      */
> 66:     public sealed interface Option<V> permits Options.OptionValue {

After looking more at the usages of Options it is not clear to me as to why generics are needed. Lookup is always performed using a non-generic Option.Key - so the API code has to be unchecked anyway. In fact, I'm not even sure you need a `value()` method. When looking at usages, Option is mostly something you create when you need to pass it to something else (e.g. a constant pool, etc.). Since the client has created the option, it is not clear to me that the client has a need to access the option value (which the API implementation can access internally by other means).

src/java.base/share/classes/jdk/internal/classfile/constantpool/AnnotationConstantValueEntry.java line 33:

> 31:  * which includes the four kinds of primitive constants, and UTF8 constants.
> 32:  */
> 33: public sealed interface AnnotationConstantValueEntry extends PoolEntry

Should this extend LoadableConstantEntry (and restrict it more) ?

src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 80:

> 78:      * Return a List composed by appending the additions to the base list.
> 79:      * @param base The base elements for the list, must not include null
> 80:      * @param additions The ClassEntrys to add to the list, must not include null

Perhaps we should use `{@code}` or {@link}` to surround type names (here and elsewhere). `ClassEntrys` looks particularly odd :-)

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 76:

> 74:      *              entry
> 75:      */
> 76:     BootstrapMethodEntry bootstrapMethodEntry(int index);

I note some inconsistency in naming - e.g. is `ByIndex` really needed, or a letfover to distinguish between different access modes (which are no longer there, it seems) ?

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 98:

> 96:     <T> T optionValue(Classfile.Option.Key option);
> 97: 
> 98:     boolean canWriteDirect(ConstantPool constantPool);

Missing javadoc in these two methods.

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 187:

> 185:      * {@return A {@link ModuleEntry} describing the module whose name
> 186:      * is encoded in the provided {@linkplain Utf8Entry}}
> 187:      * If a Module entry in the pool already describes this class,

(Here and elsewhere) - Module is capitalized. Either you use a lower case name, or you use a capital name, to refer to `ModuleEntry`, or `CONSTANT_Module_info` - e.g. a standalone `Module` with capital `M` is not a concept in this API. (personally I think lower case is just fine).

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 537:

> 535:      * @param <T> the type of the entry
> 536:      */
> 537:     <T extends PoolEntry> T maybeClone(T entry);

This feels a more primitive operation than the name suggests. Have you considered making ConstantPool extend Consumer<PoolEntry> and call this "accept" ?

src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 62:

> 60:      * {@return whether this member is a method}
> 61:      */
> 62:     boolean isMethod();

this seems surprising - after all we have separate types for methods/fields.

src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 67:

> 65:      * {@return whether this member is an interface method}
> 66:      */
> 67:     boolean isInterface();

I'd prefer to see this to `MethodRefEntry`. But again, there's an entry for interface methods, so not sure how much this is needed.

src/java.base/share/classes/jdk/internal/classfile/constantpool/MethodHandleEntry.java line 40:

> 38: 
> 39:     /**
> 40:      * {@return the reference kind of this method handle}

Where are the constants that can be used to decode the MH kind? Perhaps a reference from the javadoc could be helpful.

src/java.base/share/classes/jdk/internal/classfile/constantpool/PoolEntry.java line 55:

> 53:      * {@return the number of constant pool slots this entry consumes}
> 54:      */
> 55:     int poolEntries();

maybe `width` ?

src/java.base/share/classes/jdk/internal/classfile/constantpool/Utf8Entry.java line 47:

> 45:      * @param s the string to compare to
> 46:      */
> 47:     boolean equalsString(String s);

Whatif the provided string contains character that are not representable in Utf8? Should we throw (e.g. `IllegalArgumentException`) ?

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

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


From mcimadamore at openjdk.org  Thu Feb  9 14:15:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Feb 2023 14:15:11 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <FsYcFKipqkTseekaQt-gHYX4NIlKc4im1XkfgyZJta4=.f3a496fc-8ec1-4f4c-b89b-449fb2c92f17@github.com>

On Thu, 9 Feb 2023 12:57:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 80:
> 
>> 78:      * Return a List composed by appending the additions to the base list.
>> 79:      * @param base The base elements for the list, must not include null
>> 80:      * @param additions The ClassEntrys to add to the list, must not include null
> 
> Perhaps we should use `{@code}` or {@link}` to surround type names (here and elsewhere). `ClassEntrys` looks particularly odd :-)

It is odd to see what is essentially a list append operation in here. IMHO, these helper methods, if needed (I couldn't find uses in the JDK), should probably be added to Collections (which probably means in the jdktypes package for now) - as I don't see anything really ClassEntry/ClassDesc specific about them.

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

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


From kusrinivasan at vmware.com  Thu Feb  9 14:27:56 2023
From: kusrinivasan at vmware.com (Kumar Srinivasan)
Date: Thu, 9 Feb 2023 14:27:56 +0000
Subject: JDK-8302000: jdk11u build has a very subtle race condition
 causing builds to break.
In-Reply-To: <DB6PR0202MB269436BDC9BC402240BF91438AD89@DB6PR0202MB2694.eurprd02.prod.outlook.com>
References: <IA1PR05MB8971BFDB93530CB78555C43DB5DB9@IA1PR05MB8971.namprd05.prod.outlook.com>
 <DB6PR0202MB269436BDC9BC402240BF91438AD89@DB6PR0202MB2694.eurprd02.prod.outlook.com>
Message-ID: <IA1PR05MB8971638B6CFD45A66477E744B5D99@IA1PR05MB8971.namprd05.prod.outlook.com>

Hi Christoph,

Thanks for the response, I decided to take #2 internally for expediency.
I will start work on #3 shortly.

Thanks
Kumar


From: Langer, Christoph <christoph.langer at sap.com>
Date: Wednesday, February 8, 2023 at 2:00 PM
To: Kumar Srinivasan <kusrinivasan at vmware.com>, build-dev at openjdk.java.net <build-dev at openjdk.java.net>, jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>
Subject: RE: JDK-8302000: jdk11u build has a very subtle race condition causing builds to break.
!! External Email
Hi Kumar,

yes, I would agree. Option [3] is my preferred. It brings the code closer to upstream.

Thanks for tackling this.

Cheers
Christoph

From: build-dev <build-dev-retn at openjdk.org> On Behalf Of Kumar Srinivasan
Sent: Dienstag, 7. Februar 2023 20:20
To: build-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
Subject: JDK-8302000: jdk11u build has a very subtle race condition causing builds to break.

Hi build-team, updates-team,

We encountered a build issue since jdk 11.0.18, the root cause and possible solutions are
documented in JDK-8302000[1]. I am willing to make the change as noted in the bug.

Let me know if approach #2 or #3 is the best option, I would like
to get a consensus from the team to take the best approach.

Thanks
Kumar Srinivasan
[1] https://bugs.openjdk.org/browse/JDK-8302000<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8302000&data=05%7C01%7Ckusrinivasan%40vmware.com%7Cec886a31b5b444d8d3be08db0a1ff082%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638114904522299801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LML3MCGuVCeZlks0qows3gezHeAqPpRvxiStffPJzko%3D&reserved=0>


!! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230209/df1b5b64/attachment.htm>

From mcimadamore at openjdk.org  Thu Feb  9 15:10:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Feb 2023 15:10:37 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
Message-ID: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>

On Thu, 9 Feb 2023 08:44:41 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AttributeElement.Kind removal (#48)

src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 47:

> 45:      * {@return the start of the instruction range}
> 46:      */
> 47:     Label startScope();

I noticed that this pattern of start/endScope is here, but also in ExceptionCatch, LocalVariable and LocalVariableType. Consider using a common interface for "instructions that are associated with a range".

src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 60:

> 58:      * viewed as an array of (possibly multi-byte) characters.
> 59:      */
> 60:     int characterRangeStart();

Not sure if this belongs here - e.g. it seems to me that `characterRangeStart` is less useful than the labels. But I'm not super expert on how this code element might be used.

src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java line 63:

> 61:      * aload_0}).
> 62:      */
> 63:     sealed interface IntrinsicConstantInstruction extends ConstantInstruction

I'm not super sure of the fine-grained distinction here. The constant pool variant is interesting (as you can ask for the associated constant entry) - but the distinction between intrinsics vs. argument seems rather weak.

src/java.base/share/classes/jdk/internal/classfile/instruction/InvokeInstruction.java line 60:

> 58:      * {@return whether the class holding the method is an interface}
> 59:      */
> 60:     boolean isInterface();

This can also be tested with pattern matching on the MemberRefEntry?

src/java.base/share/classes/jdk/internal/classfile/instruction/MonitorInstruction.java line 48:

> 46:      *           which must be of kind {@link Opcode.Kind#MONITOR}
> 47:      */
> 48:     static MonitorInstruction of(Opcode op) {

There are only two cases here - perhaps also offer factories for monitor enter/exit? Or is creating instruction models a rare operation (e.g. because when adapting you always also have a CodeBuilder which has the user-friendly methods?)

src/java.base/share/classes/jdk/internal/classfile/instruction/TypeCheckInstruction.java line 39:

> 37: 
> 38: /**
> 39:  * Models an {@code instanceof} or {@code checkcast} instruction in the {@code

This seems to model both `instanceof` and `checkcast`. The latter seems to overlap partially with `ConvertInstruction`.

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

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


From duke at openjdk.org  Thu Feb  9 15:30:00 2023
From: duke at openjdk.org (Amit Kumar)
Date: Thu, 9 Feb 2023 15:30:00 GMT
Subject: RFR: 8302155: [AIX] NUM_LCPU is not required variable
Message-ID: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>

We don't need NUM_LCPU, it's just a small code change which removes this variable. I've tested it on AIX and cores are detected successfully with changes. 
@backwaterred please take look at it. 
 Suggestions are welcomed :)

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

Commit messages:
 - could be removed

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

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


From asotona at openjdk.org  Thu Feb  9 17:21:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 17:21:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <rzZgV5Ffapr1PM-e0qssZQwGCRGpcP9jv3Ua4aUY-TQ=.2540b2e9-cc38-4dfc-9f24-a31bb1b242e9@github.com>
 <WWAU3RkvjyiU0BobfO36OiaiYdtGdybXshpWKHc5AIg=.aacaf93c-95ab-433e-82a0-d6d62d92acc1@github.com>
Message-ID: <5B3FXXL7MPnEnBSe3bwnW9muJJonF4Q6F16SlstP1Sc=.801dccb6-2a93-4f47-bc02-58d8f2d6aa26@github.com>

On Tue, 7 Feb 2023 11:48:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes, performance is the main reason.
>> I'll note to do a fresh differential performance benchmarks with a HashMap.
>
> thanks

I tried HashMap with String keys and it cause performance regressions, however with Utf8Entry initialized with raw Attribute name as the HashMap key - there are no performance regressions.
I'm going to push a patch removing all the manually computed HASH_ values and fragile inlined HashMap implementation.

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

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


From asotona at openjdk.org  Thu Feb  9 17:44:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Feb 2023 17:44:29 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v16]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <pzLTfi1vjNq5DFqWIMCY-G_TjdjH6Cj23vdgRg6WNY8=.9f57283e-7869-4066-bd20-b780af8e2d34@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Proprietary hash-based mapping in Attributes replaced with HashMap using raw Utf8Entry keys

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/753e6847..ec6829e9

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

  Stats: 221 lines in 3 files changed: 27 ins; 158 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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


From ihse at openjdk.org  Thu Feb  9 19:21:43 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 9 Feb 2023 19:21:43 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v4]
In-Reply-To: <TBk67ZnOXbatCT6A_QECLAfm1-DgbGVtkJrItNWI0E0=.5e48f116-24e2-4a63-9b8b-e59da7827123@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <TBk67ZnOXbatCT6A_QECLAfm1-DgbGVtkJrItNWI0E0=.5e48f116-24e2-4a63-9b8b-e59da7827123@github.com>
Message-ID: <ErWuZHIZVop05BVSKeW_Mykr8duuL0BtYcNdqIZBaLI=.47aea845-0dbf-4c82-816c-ade73125c8bb@github.com>

On Thu, 9 Feb 2023 10:21:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
>> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
>> On macOS, sysctlbyname can be used.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   link powrprof lib without pragma

Build changes look good now. Thanks for removing the pragma.

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

Marked as reviewed by ihse (Reviewer).

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


From kbarrett at openjdk.org  Fri Feb 10 05:33:16 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 10 Feb 2023 05:33:16 GMT
Subject: RFR: 8302124: HotSpot Style Guide should permit noreturn attribute
Message-ID: <rfPu4o8CFCfQa8PE3IsyxcnG6Iw-986ceTQ9RaMGXdM=.11ecd1b4-9603-4acc-9c1d-92ea26c83851@github.com>

Please review this change to permit the use of noreturn attributes in HotSpot
code.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf
https://en.cppreference.com/w/cpp/language/attributes/noreturn

This will permit such changes as marking failed assertions and the like as
noreturn, permitting the compiler to generate better code in some cases.  This
has benefits even in product builds, since some of the relevant checks occur
in product code (such as `guarantee`, `fatal`, &etc).  It also provides a
solution to the problem described in JDK-8294031, where the potential
continued execution from a failed assertion leads to compiler warnings.

The change is written in such a way that it should be easy to add the
appropriate text for new attributes in the future.  There have been
discussions of adopting C++17, which adds several attributes.

The change to the Style Guide is forward looking, toward a time when more
attributes are available due to the adoption of a newer language standard than
the current C++14.  It is written in such a way that it should be easy to add
the appropriate text for new attributes.

Testing:
I have a prototype of making HotSpot assertions noreturn, which has been run
through mach5 tier1-8 for all Oracle-supported platforms.

This is a modification of the Style Guide, so rough consensus among the
HotSpot Group members is required to make this change. Only Group members
should vote for approval (via the github PR), though reasoned objections or
comments from anyone will be considered. A decision on this proposal will not
be made before Friday 24-Feb-2023 at 12h00 UTC.

Since we're piggybacking on github PRs here, please use the PR review process
to approve (click on Review Changes > Approve), rather than sending a "vote:
yes" email reply that would be normal for a CFV.

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

Commit messages:
 - style guide permits noreturn attributes

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

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


From stuefe at openjdk.org  Fri Feb 10 06:11:43 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 10 Feb 2023 06:11:43 GMT
Subject: RFR: 8302124: HotSpot Style Guide should permit noreturn attribute
In-Reply-To: <rfPu4o8CFCfQa8PE3IsyxcnG6Iw-986ceTQ9RaMGXdM=.11ecd1b4-9603-4acc-9c1d-92ea26c83851@github.com>
References: <rfPu4o8CFCfQa8PE3IsyxcnG6Iw-986ceTQ9RaMGXdM=.11ecd1b4-9603-4acc-9c1d-92ea26c83851@github.com>
Message-ID: <6buyk4KbjXwzeU6j7bkZgZ72S1lSe5uJgEp9eLJp12I=.3f45afa2-8e7a-4d9b-9fcc-dcf77f496212@github.com>

On Fri, 10 Feb 2023 05:26:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to permit the use of noreturn attributes in HotSpot
> code.
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf
> https://en.cppreference.com/w/cpp/language/attributes/noreturn
> 
> This will permit such changes as marking failed assertions and the like as
> noreturn, permitting the compiler to generate better code in some cases.  This
> has benefits even in product builds, since some of the relevant checks occur
> in product code (such as `guarantee`, `fatal`, &etc).  It also provides a
> solution to the problem described in JDK-8294031, where the potential
> continued execution from a failed assertion leads to compiler warnings.
> 
> The change is written in such a way that it should be easy to add the
> appropriate text for new attributes in the future.  There have been
> discussions of adopting C++17, which adds several attributes.
> 
> The change to the Style Guide is forward looking, toward a time when more
> attributes are available due to the adoption of a newer language standard than
> the current C++14.  It is written in such a way that it should be easy to add
> the appropriate text for new attributes.
> 
> Testing:
> I have a prototype of making HotSpot assertions noreturn, which has been run
> through mach5 tier1-8 for all Oracle-supported platforms.
> 
> This is a modification of the Style Guide, so rough consensus among the
> HotSpot Group members is required to make this change. Only Group members
> should vote for approval (via the github PR), though reasoned objections or
> comments from anyone will be considered. A decision on this proposal will not
> be made before Friday 24-Feb-2023 at 12h00 UTC.
> 
> Since we're piggybacking on github PRs here, please use the PR review process
> to approve (click on Review Changes > Approve), rather than sending a "vote:
> yes" email reply that would be normal for a CFV.

This sounds useful.

I try to think of cases where the fact that the compiler optimizes away follow-up instructions could be surprising. But with noreturn the compiler should warn, right, about non-reachable instructions?

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

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


From mbaesken at openjdk.org  Fri Feb 10 08:20:44 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Feb 2023 08:20:44 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v3]
In-Reply-To: <gC-IiAWXmU5IoBP8MSwvkxDzx0_s1YXVOH_oCz1xfHQ=.8f67d511-848c-4d00-a9c7-68e0f85e48b6@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <6w_kjoBCdI0udWTx7BHeQz8mh6472M9qbuyjlnINvrw=.257c0f84-ee92-4b2c-a4e9-cd7cc69fcdb9@github.com>
 <07KAKZ8yuz2HSlIkS2Y853Nepu2tYtrTDiIs37wc-_U=.6f7ee8e3-c4c0-4cc9-8b6d-cfdb381427b4@github.com>
 <gC-IiAWXmU5IoBP8MSwvkxDzx0_s1YXVOH_oCz1xfHQ=.8f67d511-848c-4d00-a9c7-68e0f85e48b6@github.com>
Message-ID: <YoripjNoDJTv8uNZHxcXzvr5AKXKQXN4WDQP1QjGMXg=.89c1b3da-fad8-4d52-9c1f-496f81cfb000@github.com>

On Wed, 8 Feb 2023 20:46:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I have no idea what possible use the "idle state" information would be in any case. We don't have that per-processor info on non-Windows.

Hi David,  there is some info about the idle states at  https://learn.microsoft.com/en-us/windows-hardware/test/wpt/cpu-analysis  ;  if you think that currently, with the info only available on Windows, it makes not that much sense to add, it I can omit it for now.  Would probably make it easier to scan through the cpu-infos and observe same MHz numbers for all and then print the same info for all processors (as I said, where I tested the MHz values were the same for all CPUs only the current idle states varied).

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

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


From mbaesken at openjdk.org  Fri Feb 10 08:20:48 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Feb 2023 08:20:48 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v4]
In-Reply-To: <TBk67ZnOXbatCT6A_QECLAfm1-DgbGVtkJrItNWI0E0=.5e48f116-24e2-4a63-9b8b-e59da7827123@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <TBk67ZnOXbatCT6A_QECLAfm1-DgbGVtkJrItNWI0E0=.5e48f116-24e2-4a63-9b8b-e59da7827123@github.com>
Message-ID: <UOV7MS0LNKpSwt3yNAmg9kJJKOoX-Hrr5gpn248008c=.edaa3f9c-4d41-48b7-b154-40ae81942b40@github.com>

On Thu, 9 Feb 2023 10:21:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
>> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
>> On macOS, sysctlbyname can be used.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   link powrprof lib without pragma

Hi Magnus, thanks for the review !

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

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


From asotona at openjdk.org  Fri Feb 10 11:01:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:01:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <8tqh8yQ47KA2UrWlPItUcFMQ97uvNXCiCJUj-PDksJo=.c9e71d26-15ef-4915-8317-651337a23af9@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <8tqh8yQ47KA2UrWlPItUcFMQ97uvNXCiCJUj-PDksJo=.c9e71d26-15ef-4915-8317-651337a23af9@github.com>
Message-ID: <IyFnpQ21meJtQ0tROFwhc4AZ2txzDXOQSLgn6XMqwg4=.8994fb5e-666b-4d58-883f-2b8844ba8843@github.com>

On Mon, 6 Feb 2023 14:13:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/BufWriter.java line 40:
>> 
>>> 38:  * to the end of the buffer, as well as to create constant pool entries.
>>> 39:  */
>>> 40: public sealed interface BufWriter
>> 
>> What is the relationship between this and ClassReader? Is one the dual of the other - e.g. is the intended use for BufWriter to write custom attributes, whereas ClassReader reads custom attributes?
>
> Yes, it is an exposure of low-level API to support custom attributes.

I see this topic has moved to classfile-api-dev mailing list.

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

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


From asotona at openjdk.org  Fri Feb 10 11:02:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:02:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v12]
In-Reply-To: <hhnDQ3Sx7BiJ05Jt32dwEKi93Rs1rkxi_kTbfJH93oI=.ace5a7f6-8ba4-42cc-9046-8ac190b12866@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Q4VeZ2yWAg85FqUDJa5hYq3jHty5H547gD0H-x3oIq0=.58d463a4-237a-4fee-bd0f-83262d49522a@github.com>
 <c022hrWNEHW76nhP_sXTQXCTjtL8jjM8r_yYv0IvbPI=.2a9cfbae-2fef-4cdb-8189-b869b1513fef@github.com>
 <FbFekphAbS5DQzn6B-uUHkX-2EF8Aq4NcijjMdlxAM0=.280a7529-4008-4539-9137-da7600e13eee@github.com>
 <kxds1bmvZ8TbtVK5iDx_hZtrqN3uywsa6GqumJ7RubE=.ffd151e4-a1ba-4018-914c-518fd122dd4f@github.com>
 <WxjOq5CRJ9OtviOIxDKH9C78bScpiGmkiBqVXLDddzU=.a5a85537-43e8-4cf4-b747-86b945999d71@github.com>
 <84RlLSIsacJTJVM-esvzoXnQ5rDEByog5b1ibFRJOE8=.05e8e7a7-2185-4e1c-b5b9-59ce3b3eea03@github.com>
 <sQwAa41mu1z226uzYIA2_v0tN8un257MDgc-WPO8SFY=.486c845c-5012-4291-bcd7-c7b0247e02dd@github.com>
 <wxsAcKZwigc4sIUexg5m-6UlOg8ZHflccTs47FJCgdQ=.5613b95e-96b0-4ced-a587-ccca3f80595d@github.com>
 <_jsw8D5-esoFp7fGSZECKF8ccwrfikwjIprRrVdCOjo=.2d8cd9f6-9c6a-4726-bc90-a4c163e8dd67@github.com>
 <LICxfIJ0QVmRRY4NJPCW_Rp4o3qhyaMrrgW
 LV-S9jHI=.4f6b40d5-d25d-4035-8fa5-186b2c735606@github.com>
 <wzHOP5Fnj3FhcNs61TKxxBZ5R6fB-oky72z_hlf1Svk=.ed56a42f-cce6-415a-b93a-d39dee6adc78@github.com>
 <hhnDQ3Sx7BiJ05Jt32dwEKi93Rs1rkxi_kTbfJH93oI=.ace5a7f6-8ba4-42cc-9046-8ac190b12866@github.com>
Message-ID: <AouWiBKLOhQJIKKQDzw0S3E1ON8Z9y7HFso4xL02-t8=.d880c319-dca6-44f6-aa7e-ed53fe8b17ca@github.com>

On Thu, 9 Feb 2023 12:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> During the fix I found the definition that `ThrowableSig` (as a super-set of `ClassTypeSig` and `TypeVarSig`) IS `Signature` - that fact is critical for processing.
>> For example when `MethodSignature` is serialized `ThrowableSig::signatureString` is critical.
>> Or `ClassRemapper` depends on the inheritence:
>> 
>> signature.throwableSignatures().stream().map(this::mapSignature).toList()
>> 
>> however `mapSignature` could not be applied on `ThrowableSig` when it does not inherit from `Signature`.
>
> I think I also see where the current hierarchy comes from - e.g. while `ThrowableSig` is a part of a method signature, it is indeed used by the production to specify a set of signatures that belong to that set. Thanks for the patience.

No problem, I had to remind myself all the reasons why does it look like Rubik's cube :)

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

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


From asotona at openjdk.org  Fri Feb 10 11:06:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:06:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <Sxvu5MMpl41oP_h0CwnQ5y6H1zVyB9JRx3Qiq502Jfg=.6c7d2e51-5361-4d4e-98a0-769bd4c5b548@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
 <XmkS1CfKIATrXGdgIqZNmfY4LI3R3wBuTj903AkwkR0=.3787d0f1-f617-426d-95ae-ac736abc43ed@github.com>
 <Sxvu5MMpl41oP_h0CwnQ5y6H1zVyB9JRx3Qiq502Jfg=.6c7d2e51-5361-4d4e-98a0-769bd4c5b548@github.com>
Message-ID: <fWqWbxdUzk-p2NPgD4au1yK6PZwjgw7BFgiF4xPVlo0=.017a1b66-f7ce-4302-ae3c-546aa1c29b07@github.com>

On Wed, 8 Feb 2023 11:19:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Any reference to an official specification of CharacterRangeInfo is appreciated.
>> Thanks.
>
>> Any reference to an official specification of CharacterRangeInfo is appreciated. Thanks.
> 
> There's this - which points back to javac code :-)
> 
> https://github.com/jacoco/jacoco/wiki/CharacterRangeTable

Unfortunately I don't have enough information to provide static helpers.

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

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


From asotona at openjdk.org  Fri Feb 10 11:07:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:07:02 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v13]
In-Reply-To: <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Ej4u9wRtUuLS5LJhMkXwmown_MGuwR0gH9ruJ1A1g30=.f6405576-6655-4252-9135-ebc77765436e@github.com>
 <u6VmkXvghsyyf7qwyHyDpcqZ-wVCfFnZgOoB_wiz2-A=.ce2c44e1-81b0-4851-811c-5f4fd3fdda62@github.com>
Message-ID: <NBSJ_Jl4C2jrK7fT8udubne73Fr19mQZU6eRFHsYmIU=.16038547-5c8f-4e46-bb5a-8dc2aeb866b2@github.com>

On Tue, 7 Feb 2023 16:04:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - javadoc fixes
>>  - obsolete identifiers and unused imports cleanup
>>  - TypeAnnotation.TypePathComponent cleanup
>
> src/java.base/share/classes/jdk/internal/classfile/attribute/ModuleExportInfo.java line 107:
> 
>> 105:      * @param exportsTo the modules to which this package is exported
>> 106:      */
>> 107:     static ModuleExportInfo of(PackageEntry exports,
> 
> (Here and elsewhere) - should there be factories also taking a PackageDesc (which seems to be an extension of the ClassDesc API, but for packages) ?

yes, they are missing, I'm working on it.

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

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


From asotona at openjdk.org  Fri Feb 10 11:15:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:15:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <C-fd3WUG0sCiQVVFekGvM1JKgjN5PdkxmCIifWdrGFw=.7fb95367-0539-4b8b-98d4-2a50c5058e57@github.com>

On Thu, 9 Feb 2023 13:03:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/AnnotationConstantValueEntry.java line 33:
> 
>> 31:  * which includes the four kinds of primitive constants, and UTF8 constants.
>> 32:  */
>> 33: public sealed interface AnnotationConstantValueEntry extends PoolEntry
> 
> Should this extend LoadableConstantEntry (and restrict it more) ?

`LoadableConstantEntry` and `AnnotationConstantValueEntry` are just partially overlapping according to the spec.
The biggest difference (and source of confusion) is that `StringEntry` is `LoadableConstantEntry`, however not `AnnotationConstantValueEntry` and `Utf8Entry` is `AnnotationConstantValueEntry`, however not `LoadableConstantEntry`.

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

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


From asotona at openjdk.org  Fri Feb 10 11:20:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:20:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <6gCIlUafIspeaYjIs6AlFuRqJtUsuOqjKOSDBs8kYV4=.14b51d52-5b74-4918-a3ab-a7fda35a723b@github.com>

On Thu, 9 Feb 2023 14:11:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/Utf8Entry.java line 47:
> 
>> 45:      * @param s the string to compare to
>> 46:      */
>> 47:     boolean equalsString(String s);
> 
> Whatif the provided string contains character that are not representable in Utf8? Should we throw (e.g. `IllegalArgumentException`) ?

I would rather expect `false` value returned, however this case is probably not covered by tests.

> src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 60:
> 
>> 58:      * viewed as an array of (possibly multi-byte) characters.
>> 59:      */
>> 60:     int characterRangeStart();
> 
> Not sure if this belongs here - e.g. it seems to me that `characterRangeStart` is less useful than the labels. But I'm not super expert on how this code element might be used.

It is character range within the source code, not the bytecode.

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

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


From asotona at openjdk.org  Fri Feb 10 11:29:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Feb 2023 11:29:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
Message-ID: <zl4ItbIt1wr2_QaGpv2FYj9yaLrhfrtfNYZvZKa9su8=.767de808-a449-4683-9580-7b8351583aea@github.com>

On Thu, 9 Feb 2023 15:01:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/MonitorInstruction.java line 48:
> 
>> 46:      *           which must be of kind {@link Opcode.Kind#MONITOR}
>> 47:      */
>> 48:     static MonitorInstruction of(Opcode op) {
> 
> There are only two cases here - perhaps also offer factories for monitor enter/exit? Or is creating instruction models a rare operation (e.g. because when adapting you always also have a CodeBuilder which has the user-friendly methods?)

Each of the approaches server different purposes. `CodeBuilder` with user-friendly methods is my first choice when typing code from scratch, however in transformations you usually start with a pattern switch and it is a Classfile API "standard" to find relevant factory methods in each `Instruction` sub-type.

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

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


From tsteele at openjdk.org  Fri Feb 10 17:02:50 2023
From: tsteele at openjdk.org (Tyler Steele)
Date: Fri, 10 Feb 2023 17:02:50 GMT
Subject: RFR: 8302155: [AIX] NUM_LCPU is not required variable
In-Reply-To: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
References: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
Message-ID: <M_9NObBItcAr87d3kDYi-LcdNF2wGzI92SWO3FnEH2g=.bd681983-7ddb-48ab-b6c4-aa017c0d0540@github.com>

On Thu, 9 Feb 2023 15:21:42 GMT, Amit Kumar <duke at openjdk.org> wrote:

> We don't need NUM_LCPU, it's just a small code change which removes this variable. I've tested it on AIX and cores are detected successfully with changes. 
> @backwaterred please take look at it. 
>  Suggestions are welcomed :)

I wanted to point out these changes are semantically different in the error case. If we don't get the output we expect from lparstat we potentially overwrite the NUM_CORES var with the empty string. Previously, the code protected against this by testing if the result stored in the temp variable was non-empty before committing to them.

Checking the [documentation](https://www.ibm.com/docs/en/aix/7.2?topic=l-lparstat-command) for AIX 7.1-7.3, it seems like the syntax is stable, so removing this check seems reasonable to me.

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

Marked as reviewed by tsteele (Committer).

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


From mcimadamore at openjdk.org  Fri Feb 10 17:16:14 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 Feb 2023 17:16:14 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <C-fd3WUG0sCiQVVFekGvM1JKgjN5PdkxmCIifWdrGFw=.7fb95367-0539-4b8b-98d4-2a50c5058e57@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <C-fd3WUG0sCiQVVFekGvM1JKgjN5PdkxmCIifWdrGFw=.7fb95367-0539-4b8b-98d4-2a50c5058e57@github.com>
Message-ID: <EeI_pmAHhHpCjUqBJ_pf0Pof4Wb4VGa9sSu9K9yFwJI=.4b5f50be-50b9-44e3-8c90-04651d888571@github.com>

On Fri, 10 Feb 2023 11:12:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/AnnotationConstantValueEntry.java line 33:
>> 
>>> 31:  * which includes the four kinds of primitive constants, and UTF8 constants.
>>> 32:  */
>>> 33: public sealed interface AnnotationConstantValueEntry extends PoolEntry
>> 
>> Should this extend LoadableConstantEntry (and restrict it more) ?
>
> `LoadableConstantEntry` and `AnnotationConstantValueEntry` are just partially overlapping according to the spec.
> The biggest difference (and source of confusion) is that `StringEntry` is `LoadableConstantEntry`, however not `AnnotationConstantValueEntry` and `Utf8Entry` is `AnnotationConstantValueEntry`, however not `LoadableConstantEntry`.

Ugh - you are right of course!

>> src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 60:
>> 
>>> 58:      * viewed as an array of (possibly multi-byte) characters.
>>> 59:      */
>>> 60:     int characterRangeStart();
>> 
>> Not sure if this belongs here - e.g. it seems to me that `characterRangeStart` is less useful than the labels. But I'm not super expert on how this code element might be used.
>
> It is character range within the source code, not the bytecode.

I see - I was probably confusing myself (I wonder if the method names played some part in that)

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

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


From jwilhelm at openjdk.org  Fri Feb 10 18:19:36 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 10 Feb 2023 18:19:36 GMT
Subject: [jdk20] RFR: 8301886: Remove EA from JDK 20 version string starting
 with Initial RC promotion B35 on February 09, 2023
Message-ID: <g4sNFo4P5BkP9nkXkXrHOStecHW-j73AkXqT9_53lEI=.f4f3c7a8-e6e0-4b19-b427-3f85e75c1969@github.com>

EA removed

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

Commit messages:
 - 8301886: Remove EA from JDK 20 version string starting with Initial RC promotion B35 on February 09, 2023

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

PR: https://git.openjdk.org/jdk20/pull/123


From iris at openjdk.org  Fri Feb 10 18:37:55 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 10 Feb 2023 18:37:55 GMT
Subject: [jdk20] RFR: 8301886: Remove EA from JDK 20 version string
 starting with Initial RC promotion B35 on February 09, 2023
In-Reply-To: <g4sNFo4P5BkP9nkXkXrHOStecHW-j73AkXqT9_53lEI=.f4f3c7a8-e6e0-4b19-b427-3f85e75c1969@github.com>
References: <g4sNFo4P5BkP9nkXkXrHOStecHW-j73AkXqT9_53lEI=.f4f3c7a8-e6e0-4b19-b427-3f85e75c1969@github.com>
Message-ID: <oIbMIEgs7XLYRQ0I-3fb2XBW8XxzHIvwprZYLKxinck=.38bec6e4-3562-4406-ac05-de0b092d4698@github.com>

On Fri, 10 Feb 2023 18:12:19 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> EA removed

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/123


From erikj at openjdk.org  Fri Feb 10 18:52:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 18:52:52 GMT
Subject: [jdk20] RFR: 8301886: Remove EA from JDK 20 version string
 starting with Initial RC promotion B35 on February 09, 2023
In-Reply-To: <g4sNFo4P5BkP9nkXkXrHOStecHW-j73AkXqT9_53lEI=.f4f3c7a8-e6e0-4b19-b427-3f85e75c1969@github.com>
References: <g4sNFo4P5BkP9nkXkXrHOStecHW-j73AkXqT9_53lEI=.f4f3c7a8-e6e0-4b19-b427-3f85e75c1969@github.com>
Message-ID: <2zRGNQg9WaWnPO8RYuJPrIc-dGanOSGheW5f-j7KDSM=.e5661005-e76c-467c-8f68-01eb85e9f924@github.com>

On Fri, 10 Feb 2023 18:12:19 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> EA removed

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/123


From jwilhelm at openjdk.org  Fri Feb 10 19:28:52 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 10 Feb 2023 19:28:52 GMT
Subject: [jdk20] Integrated: 8301886: Remove EA from JDK 20 version string
 starting with Initial RC promotion B35 on February 09, 2023
In-Reply-To: <g4sNFo4P5BkP9nkXkXrHOStecHW-j73AkXqT9_53lEI=.f4f3c7a8-e6e0-4b19-b427-3f85e75c1969@github.com>
References: <g4sNFo4P5BkP9nkXkXrHOStecHW-j73AkXqT9_53lEI=.f4f3c7a8-e6e0-4b19-b427-3f85e75c1969@github.com>
Message-ID: <eyosWQiU4jKPLW9nKj7uwJ48D3qYMXV2_rMKEvTzANI=.a5393173-4f2f-4667-8008-5ff14cde6d5e@github.com>

On Fri, 10 Feb 2023 18:12:19 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> EA removed

This pull request has now been integrated.

Changeset: 82749901
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/82749901b1497f524e53e47c45708c8e4a63c8b9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8301886: Remove EA from JDK 20 version string starting with Initial RC promotion B35 on February 09, 2023

Reviewed-by: iris, erikj

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

PR: https://git.openjdk.org/jdk20/pull/123


From duke at openjdk.org  Sat Feb 11 20:24:28 2023
From: duke at openjdk.org (SWinxy)
Date: Sat, 11 Feb 2023 20:24:28 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v2]
In-Reply-To: <E7Uak5J0FFV1ik7CMYbs3Z87N_15lGVRcs5ZTsBtWhE=.1f760cef-d01b-446f-b6bc-4f7248ddccf0@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
 <E7Uak5J0FFV1ik7CMYbs3Z87N_15lGVRcs5ZTsBtWhE=.1f760cef-d01b-446f-b6bc-4f7248ddccf0@github.com>
Message-ID: <JH29DUmCrvwSzt4adhyWMk4NTW_kDBGW0SGHx6brpbA=.0ee91f53-5c8f-49e7-a469-549338ee6091@github.com>

On Fri, 20 Jan 2023 12:01:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
>> 
>> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge remote-tracking branch 'origin' into awt-warning-cleanup
>  - Copyright
>  - snprintf
>  - cl analyze
>  - Fix non-debug warning
>  - Restore suppressions
>  - Fix warnings
>  - WIP: reenable awt warnings
>  - Fix warnings

These changes look fine to me as well. Built and ran a couple dozen tests. `D3DBlitLoops.cpp` looks to have had a hidden bug that is now fixed with this patch. Granted, I am not to be trusted with native code.

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

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

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


From magnus.ihse.bursie at oracle.com  Mon Feb 13 13:42:51 2023
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 13 Feb 2023 14:42:51 +0100
Subject: Hermetic Java (static image packaging/formatting) investigation
 and proposal
In-Reply-To: <CALrW1jxoHpb86u1WRFH4hSOfbR7NqdKhNu9G7hmAXamo75qorg@mail.gmail.com>
References: <CALrW1jw6yPEDPwPNCk+y0qVuQRkhVCynQbjxfbrYdLCi6xKpdQ@mail.gmail.com>
 <CALrW1jwMKVtyTRw1apDhZgvaq65pC+mjVg7b_Rb31BgCx0_17w@mail.gmail.com>
 <3ff54387-7a5f-8825-8c7f-f7ed92b691af@oracle.com>
 <CALrW1jx-iYvY5ibOnyFDpg77v=tJ9ZfGv5PfMZbJ0HwbZo43rg@mail.gmail.com>
 <1bb33f0d-2bb0-946f-6258-ade85c521f5d@oracle.com>
 <CALrW1jxoHpb86u1WRFH4hSOfbR7NqdKhNu9G7hmAXamo75qorg@mail.gmail.com>
Message-ID: <a4680157-f89e-062f-96c0-773c85904fc4@oracle.com>

Hi Jiangli,

On 2023-02-08 03:08, Jiangli Zhou wrote:
> Hi Brian,
>
> Here are the main buckets of the changes discovered in JDK/VM to
> support the proposed hermetic image:
>
> 1) Resolve symbol conflicts to fully support JDK static builds. Those
> are mainly caused by duplicated symbols defined in different native
> libraries or VM code.
>
> 2) Complete the built-in native library support in JDK. For easier and
> more reliable testing/release/deployment, we wanted to support JDK
> dynamic and static builds with the same set of object files (.o).
> We've changed to use unique names for
> JNI_OnLoad|JNI_OnUnload|Agent_OnLoad|Agent_OnUnload|Agent_OnAttach in
> different JDK JNI libraries by default. For both dynamic linked and
> static linked JDK builds, we use unique symbols for JNI_OnLoad
> function and friends. However, non-builtin application JNI libraries
> can still have the default JNI_OnLoad|... naming. We still properly
> support application JNI libraries using the default JNI_OnLoad (and
> friends) naming.
>
> As we wanted to produce dynamic and static builds from the same set of
> object files, we've moved away from using the STATIC_BUILD macro.
>
> We've also done some makefile work to build both dynamic shared
> libraries (DSOs) and static libraries, within one JDK build.

This sounds like interesting work indeed. However, I am inclined to 
agree with Andrew and wonder how much it relates to Project Leyden. It 
might be that Leyden will need some kind of packaging story, and that 
this can have a role to play in that. But it is not immediately clear 
that it does fit in, and indeed, I think this is not one of Leyden main 
problem areas at the time.

But your code sounds very much interesting from a pure build 
perspective! For at least this part of the code, I think you should 
ignore Leyden for now, and just see if the static build changes you have 
made could be fit for inclusion in OpenJDK.

The static build part of the build system has been sadly neglected due 
to resource limitations, for a long time. :( The rudimentary system 
(actually, more like two separate systems) we have was put in place 
mostly due to external requirements from Project Mobile and the Graal 
integration, and was tacked on mostly as an after-thought. It is not 
regularly tested, and I'd frankly be surprised if it actually works 
right now. So I fully understand if you have been staying away from 
STATIC_BUILD. :)

It sounds like you have created a more dynamic system to be able to 
select per library, if it should be compiled statically or dynamically. 
Do I understand you correctly? If done correctly, it can probably help 
bring a better abstraction to the build process.

If you are willing to contribute your work to OpenJDK, I would 
definitely be interested in studying it in detail. As you might be 
aware, contributions to OpenJDK must be done on the OpenJDK 
infrastructure. One way to do this is to create a branch in the sandbox 
repo[1], and push your changes there.

If it turns out to be of use for Project Leyden, all the better if it is 
already in place. And if it turns out that this is orthogonal to Project 
Leyden, I still think a cleanup in this area might be beneficial for all 
of the JDK.

/Magnus

[1] https://github.com/openjdk/jdk-sandbox



From ihse at openjdk.org  Mon Feb 13 14:25:31 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 13 Feb 2023 14:25:31 GMT
Subject: RFR: 8302155: [AIX] NUM_LCPU is not required variable
In-Reply-To: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
References: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
Message-ID: <2iMVtE4loQwKfvabwNR2P9c7rBqSuNBaOEvtSogkbiQ=.64e46892-2fcb-4c02-8b92-aa6a3de71e71@github.com>

On Thu, 9 Feb 2023 15:21:42 GMT, Amit Kumar <duke at openjdk.org> wrote:

> We don't need NUM_LCPU, it's just a small code change which removes this variable. I've tested it on AIX and cores are detected successfully with changes. 
> @backwaterred please take look at it. 
>  Suggestions are welcomed :)

(github needs me to repeat the comment here)

make/autoconf/build-performance.m4 line 41:

> 39:     NUM_CORES=`/usr/sbin/sysctl -n hw.ncpu`
> 40:   elif test "x$OPENJDK_BUILD_OS" = xaix ; then
> 41:     NUM_CORES=`lparstat -m 2> /dev/null | $GREP -o "lcpu=[[0-9]]*" | $CUT -d "=" -f 2`

The assignment of `NUM_CORES=0` on line 29 was to cover the case that `lparstat` failed. If you are certain that it works, fine, make this change. But please also remove the unnecessary initialization of `NUM_CORES` then.

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

Changes requested by ihse (Reviewer).

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


From duke at openjdk.org  Mon Feb 13 15:42:12 2023
From: duke at openjdk.org (Amit Kumar)
Date: Mon, 13 Feb 2023 15:42:12 GMT
Subject: RFR: 8302155: [AIX] NUM_LCPU is not required variable [v2]
In-Reply-To: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
References: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
Message-ID: <GVPOPyqdEPy6II8VblgkM0k2cZxLpfNBSW-P-mc6BXM=.7cd052da-8fce-4bd7-85f4-eee408382197@github.com>

> We don't need NUM_LCPU, it's just a small code change which removes this variable. I've tested it on AIX and cores are detected successfully with changes. 
> @backwaterred please take look at it. 
>  Suggestions are welcomed :)

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

 - addressing comment from magicus
 - Merge branch 'aix_build_variable' of github.com:offamitkumar/jdk into aix_build_variable
 - could be removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12494/files
  - new: https://git.openjdk.org/jdk/pull/12494/files/08a528f7..17e3e902

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

  Stats: 15746 lines in 522 files changed: 7855 ins; 3432 del; 4459 mod
  Patch: https://git.openjdk.org/jdk/pull/12494.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12494/head:pull/12494

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


From ihse at openjdk.org  Mon Feb 13 16:17:34 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 13 Feb 2023 16:17:34 GMT
Subject: RFR: 8302155: [AIX] NUM_LCPU is not required variable [v2]
In-Reply-To: <GVPOPyqdEPy6II8VblgkM0k2cZxLpfNBSW-P-mc6BXM=.7cd052da-8fce-4bd7-85f4-eee408382197@github.com>
References: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
 <GVPOPyqdEPy6II8VblgkM0k2cZxLpfNBSW-P-mc6BXM=.7cd052da-8fce-4bd7-85f4-eee408382197@github.com>
Message-ID: <IB6qCX1zQvVF9HkiuCqvUqhZMdka2BQ8OmlICbawEbg=.8d493c9a-392e-44f3-97c1-6ee28eb8d203@github.com>

On Mon, 13 Feb 2023 15:42:12 GMT, Amit Kumar <duke at openjdk.org> wrote:

>> We don't need NUM_LCPU, it's just a small code change which removes this variable. I've tested it on AIX and cores are detected successfully with changes. 
>> @backwaterred please take look at it. 
>>  Suggestions are welcomed :)
>
> Amit Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - addressing comment from magicus
>  - Merge branch 'aix_build_variable' of github.com:offamitkumar/jdk into aix_build_variable
>  - could be removed

The merge warning from the bots sounded a bit scary; I don't understand what git move you did there, but the end result seems to look fine anyway.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Mon Feb 13 16:20:27 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 13 Feb 2023 16:20:27 GMT
Subject: RFR: 8302155: [AIX] NUM_LCPU is not required variable [v2]
In-Reply-To: <GVPOPyqdEPy6II8VblgkM0k2cZxLpfNBSW-P-mc6BXM=.7cd052da-8fce-4bd7-85f4-eee408382197@github.com>
References: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
 <GVPOPyqdEPy6II8VblgkM0k2cZxLpfNBSW-P-mc6BXM=.7cd052da-8fce-4bd7-85f4-eee408382197@github.com>
Message-ID: <VH4Gobq2WJiSuGFqTSymje62Gq7pVCNwSzhtzEAJr9U=.68a7f368-9c48-4aca-af8b-1416307b6c4f@github.com>

On Mon, 13 Feb 2023 15:42:12 GMT, Amit Kumar <duke at openjdk.org> wrote:

>> We don't need NUM_LCPU, it's just a small code change which removes this variable. I've tested it on AIX and cores are detected successfully with changes. 
>> @backwaterred please take look at it. 
>>  Suggestions are welcomed :)
>
> Amit Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - addressing comment from magicus
>  - Merge branch 'aix_build_variable' of github.com:offamitkumar/jdk into aix_build_variable
>  - could be removed

I can sponsor this change, unless you have some other sponsor already.

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

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


From duke at openjdk.org  Mon Feb 13 16:27:26 2023
From: duke at openjdk.org (Amit Kumar)
Date: Mon, 13 Feb 2023 16:27:26 GMT
Subject: RFR: 8302155: [AIX] NUM_LCPU is not required variable [v2]
In-Reply-To: <VH4Gobq2WJiSuGFqTSymje62Gq7pVCNwSzhtzEAJr9U=.68a7f368-9c48-4aca-af8b-1416307b6c4f@github.com>
References: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
 <GVPOPyqdEPy6II8VblgkM0k2cZxLpfNBSW-P-mc6BXM=.7cd052da-8fce-4bd7-85f4-eee408382197@github.com>
 <VH4Gobq2WJiSuGFqTSymje62Gq7pVCNwSzhtzEAJr9U=.68a7f368-9c48-4aca-af8b-1416307b6c4f@github.com>
Message-ID: <xMzSnftSmllmE3GudBHsNBqsS_G30YI3Ed9B6mNPJks=.edccdf93-c8a2-4171-8684-c5abec35e60d@github.com>

On Mon, 13 Feb 2023 16:17:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Amit Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - addressing comment from magicus
>>  - Merge branch 'aix_build_variable' of github.com:offamitkumar/jdk into aix_build_variable
>>  - could be removed
>
> I can sponsor this change, unless you have some other sponsor already.

Sure @magicus ,

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

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


From duke at openjdk.org  Mon Feb 13 19:04:39 2023
From: duke at openjdk.org (Amit Kumar)
Date: Mon, 13 Feb 2023 19:04:39 GMT
Subject: Integrated: 8302155: [AIX] NUM_LCPU is not required variable
In-Reply-To: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
References: <qv83559DfRYaD_Y26uN3eCtRf5IzNu08OdH9jAxANnU=.8d794b4e-9d2c-432d-a139-d7bb2bceaaf9@github.com>
Message-ID: <dDMzGcuYE_T66fWrlxZbjxiQMdbP637ykRGPrfhT37M=.1d4dc70b-48eb-4e3f-9d76-3a78b71c6b26@github.com>

On Thu, 9 Feb 2023 15:21:42 GMT, Amit Kumar <duke at openjdk.org> wrote:

> We don't need NUM_LCPU, it's just a small code change which removes this variable. I've tested it on AIX and cores are detected successfully with changes. 
> @backwaterred please take look at it. 
>  Suggestions are welcomed :)

This pull request has now been integrated.

Changeset: d503c664
Author:    Amit Kumar <amitlocham09 at icloud.com>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d503c66400f37a44406419fab280e64e3d7c9014
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8302155: [AIX] NUM_LCPU is not required variable

Reviewed-by: tsteele, ihse

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

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


From jianglizhou at google.com  Mon Feb 13 23:52:14 2023
From: jianglizhou at google.com (Jiangli Zhou)
Date: Mon, 13 Feb 2023 15:52:14 -0800
Subject: Hermetic Java (static image packaging/formatting) investigation
 and proposal
In-Reply-To: <a4680157-f89e-062f-96c0-773c85904fc4@oracle.com>
References: <CALrW1jw6yPEDPwPNCk+y0qVuQRkhVCynQbjxfbrYdLCi6xKpdQ@mail.gmail.com>
 <CALrW1jwMKVtyTRw1apDhZgvaq65pC+mjVg7b_Rb31BgCx0_17w@mail.gmail.com>
 <3ff54387-7a5f-8825-8c7f-f7ed92b691af@oracle.com>
 <CALrW1jx-iYvY5ibOnyFDpg77v=tJ9ZfGv5PfMZbJ0HwbZo43rg@mail.gmail.com>
 <1bb33f0d-2bb0-946f-6258-ade85c521f5d@oracle.com>
 <CALrW1jxoHpb86u1WRFH4hSOfbR7NqdKhNu9G7hmAXamo75qorg@mail.gmail.com>
 <a4680157-f89e-062f-96c0-773c85904fc4@oracle.com>
Message-ID: <CALrW1jyG1o9NMvDjyaNKEOaKq1TDJbV97Md801MgcBUp7wSJkQ@mail.gmail.com>

Hi Magnus,

Thanks for the thoughts! Please see comments inlined below.

On Mon, Feb 13, 2023 at 5:43 AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> Hi Jiangli,
>
> On 2023-02-08 03:08, Jiangli Zhou wrote:
> > Hi Brian,
> >
> > Here are the main buckets of the changes discovered in JDK/VM to
> > support the proposed hermetic image:
> >
> > 1) Resolve symbol conflicts to fully support JDK static builds. Those
> > are mainly caused by duplicated symbols defined in different native
> > libraries or VM code.
> >
> > 2) Complete the built-in native library support in JDK. For easier and
> > more reliable testing/release/deployment, we wanted to support JDK
> > dynamic and static builds with the same set of object files (.o).
> > We've changed to use unique names for
> > JNI_OnLoad|JNI_OnUnload|Agent_OnLoad|Agent_OnUnload|Agent_OnAttach in
> > different JDK JNI libraries by default. For both dynamic linked and
> > static linked JDK builds, we use unique symbols for JNI_OnLoad
> > function and friends. However, non-builtin application JNI libraries
> > can still have the default JNI_OnLoad|... naming. We still properly
> > support application JNI libraries using the default JNI_OnLoad (and
> > friends) naming.
> >
> > As we wanted to produce dynamic and static builds from the same set of
> > object files, we've moved away from using the STATIC_BUILD macro.
> >
> > We've also done some makefile work to build both dynamic shared
> > libraries (DSOs) and static libraries, within one JDK build.
>
> This sounds like interesting work indeed. However, I am inclined to
> agree with Andrew and wonder how much it relates to Project Leyden. It
> might be that Leyden will need some kind of packaging story, and that
> this can have a role to play in that. But it is not immediately clear
> that it does fit in, and indeed, I think this is not one of Leyden main
> problem areas at the time.
>
> But your code sounds very much interesting from a pure build
> perspective! For at least this part of the code, I think you should
> ignore Leyden for now, and just see if the static build changes you have
> made could be fit for inclusion in OpenJDK.
>
> The static build part of the build system has been sadly neglected due
> to resource limitations, for a long time. :( The rudimentary system
> (actually, more like two separate systems) we have was put in place
> mostly due to external requirements from Project Mobile and the Graal
> integration, and was tacked on mostly as an after-thought. It is not
> regularly tested, and I'd frankly be surprised if it actually works
> right now. So I fully understand if you have been staying away from
> STATIC_BUILD. :)
>
> It sounds like you have created a more dynamic system to be able to
> select per library, if it should be compiled statically or dynamically.
> Do I understand you correctly? If done correctly, it can probably help
> bring a better abstraction to the build process.
>

For JDK/hotspot natives, our experiment/prototype builds all the JDK
regular artifacts (e.g. lib/.../*.so) that the existing JDK build produces.
Additionally, it also creates the JDK static libraries (e.g.
lib_static/*.a) and a bin/javastatic (with most of the needed JDK static
libraries statically linked into the launcher, for testing purposes only,
such as running jtreg tests) in the binary, as part of the single JDK
build. The hermetic image creation is done as a post process, which takes
the needed pre-built JDK static libraries for linking into the final
executable. The post process is done outside the JDK build. The JDK runtime
support is enhanced to be able to support both built-in libraries and
dynamically loaded shared libraries.

It doesn't seem to be problematic to get the JDK static support into
OpenJDK first. It's especially helpful for you or erikj@ to look at the
makefiles changes and help massage the changes according to the JDK build
standard.


>
> If you are willing to contribute your work to OpenJDK, I would
> definitely be interested in studying it in detail.


Thanks!


> As you might be
> aware, contributions to OpenJDK must be done on the OpenJDK
> infrastructure. One way to do this is to create a branch in the sandbox
> repo[1], and push your changes there.
>

Will get back to you on this, after some explorations on open sourcing the
changes.


>
> If it turns out to be of use for Project Leyden, all the better if it is
> already in place. And if it turns out that this is orthogonal to Project
> Leyden, I still think a cleanup in this area might be beneficial for all
> of the JDK.
>

All sounds good!

Best,
Jiangli


>
> /Magnus
>
> [1] https://github.com/openjdk/jdk-sandbox
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230213/01541088/attachment.htm>

From magnus.ihse.bursie at oracle.com  Tue Feb 14 08:55:06 2023
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 14 Feb 2023 09:55:06 +0100
Subject: Hermetic Java (static image packaging/formatting) investigation
 and proposal
In-Reply-To: <CALrW1jyG1o9NMvDjyaNKEOaKq1TDJbV97Md801MgcBUp7wSJkQ@mail.gmail.com>
References: <CALrW1jw6yPEDPwPNCk+y0qVuQRkhVCynQbjxfbrYdLCi6xKpdQ@mail.gmail.com>
 <CALrW1jwMKVtyTRw1apDhZgvaq65pC+mjVg7b_Rb31BgCx0_17w@mail.gmail.com>
 <3ff54387-7a5f-8825-8c7f-f7ed92b691af@oracle.com>
 <CALrW1jx-iYvY5ibOnyFDpg77v=tJ9ZfGv5PfMZbJ0HwbZo43rg@mail.gmail.com>
 <1bb33f0d-2bb0-946f-6258-ade85c521f5d@oracle.com>
 <CALrW1jxoHpb86u1WRFH4hSOfbR7NqdKhNu9G7hmAXamo75qorg@mail.gmail.com>
 <a4680157-f89e-062f-96c0-773c85904fc4@oracle.com>
 <CALrW1jyG1o9NMvDjyaNKEOaKq1TDJbV97Md801MgcBUp7wSJkQ@mail.gmail.com>
Message-ID: <106cb683-3ee3-810a-0a23-c6a4a0083dc4@oracle.com>

On 2023-02-14 00:52, Jiangli Zhou wrote:

> Hi?Magnus,
>
> Thanks for the thoughts! Please see comments inlined below.
>
> On Mon, Feb 13, 2023 at 5:43 AM Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com> wrote:
>
>     Hi Jiangli,
>
>     On 2023-02-08 03:08, Jiangli Zhou wrote:
>     > Hi Brian,
>     >
>     > Here are the main buckets of the changes discovered in JDK/VM to
>     > support the proposed hermetic image:
>     >
>     > 1) Resolve symbol conflicts to fully support JDK static builds.
>     Those
>     > are mainly caused by duplicated symbols defined in different native
>     > libraries or VM code.
>     >
>     > 2) Complete the built-in native library support in JDK. For
>     easier and
>     > more reliable testing/release/deployment, we wanted to support JDK
>     > dynamic and static builds with the same set of object files (.o).
>     > We've changed to use unique names for
>     >
>     JNI_OnLoad|JNI_OnUnload|Agent_OnLoad|Agent_OnUnload|Agent_OnAttach in
>     > different JDK JNI libraries by default. For both dynamic linked and
>     > static linked JDK builds, we use unique symbols for JNI_OnLoad
>     > function and friends. However, non-builtin application JNI libraries
>     > can still have the default JNI_OnLoad|... naming. We still properly
>     > support application JNI libraries using the default JNI_OnLoad (and
>     > friends) naming.
>     >
>     > As we wanted to produce dynamic and static builds from the same
>     set of
>     > object files, we've moved away from using the STATIC_BUILD macro.
>     >
>     > We've also done some makefile work to build both dynamic shared
>     > libraries (DSOs) and static libraries, within one JDK build.
>
>     This sounds like interesting work indeed. However, I am inclined to
>     agree with Andrew and wonder how much it relates to Project
>     Leyden. It
>     might be that Leyden will need some kind of packaging story, and that
>     this can have a role to play in that. But it is not immediately clear
>     that it does fit in, and indeed, I think this is not one of Leyden
>     main
>     problem areas at the time.
>
>     But your code sounds very much interesting from a pure build
>     perspective! For at least this part of the code, I think you should
>     ignore Leyden for now, and just see if the static build changes
>     you have
>     made could be fit for inclusion in OpenJDK.
>
>     The static build part of the build system has been sadly neglected
>     due
>     to resource limitations, for a long time. :( The rudimentary system
>     (actually, more like two separate systems) we have was put in place
>     mostly due to external requirements from Project Mobile and the Graal
>     integration, and was tacked on mostly as an after-thought. It is not
>     regularly tested, and I'd frankly be surprised if it actually works
>     right now. So I fully understand if you have been staying away from
>     STATIC_BUILD. :)
>
>     It sounds like you have created a more dynamic system to be able to
>     select per library, if it should be compiled statically or
>     dynamically.
>     Do I understand you correctly? If done correctly, it can probably
>     help
>     bring a better abstraction to the build process.
>
>
> For JDK/hotspot natives, our experiment/prototype builds all the JDK 
> regular artifacts?(e.g. lib/.../*.so) that the existing JDK build 
> produces. Additionally, it also creates the JDK static libraries (e.g. 
> lib_static/*.a) and a bin/javastatic?(with most of the?needed JDK 
> static libraries statically linked into the launcher, for testing 
> purposes only, such as running jtreg tests) in the binary, as part of 
> the single JDK build. The hermetic image creation is done as a post 
> process, which takes the needed pre-built?JDK static libraries for 
> linking into the final executable. The post process is done outside 
> the JDK build. The JDK runtime support is enhanced to be able to 
> support both built-in libraries and dynamically loaded shared libraries.
>
> It doesn't seem to be problematic to get the JDK static support into 
> OpenJDK first. It's especially helpful for you or erikj@ to look at 
> the makefiles changes and help massage the?changes according to the 
> JDK build standard.
>
>
>     If you are willing to contribute your work to OpenJDK, I would
>     definitely be interested in studying it in detail. 
>
>
> Thanks!
>
>     As you might be
>     aware, contributions to OpenJDK must be done on the OpenJDK
>     infrastructure. One way to do this is to create a branch in the
>     sandbox
>     repo[1], and push your changes there.
>
>
> Will get back to you on this, after some explorations on open sourcing 
> the changes.

Let me know when you are done with that process.

/Magnus

>
>     If it turns out to be of use for Project Leyden, all the better if
>     it is
>     already in place. And if it turns out that this is orthogonal to
>     Project
>     Leyden, I still think a cleanup in this area might be beneficial
>     for all
>     of the JDK.
>
>
> All sounds good!
>
> Best,
> Jiangli
>
>
>     /Magnus
>
>     [1] https://github.com/openjdk/jdk-sandbox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230214/3e783c3d/attachment.htm>

From ihse at openjdk.org  Tue Feb 14 09:58:47 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 14 Feb 2023 09:58:47 GMT
Subject: RFR: 8295795: hsdis does not build with binutils 2.39+
In-Reply-To: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
References: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
Message-ID: <jtdOzgZNXcrZzec8_RaYuxseDEWD9zQsb2G_9THWCtM=.6ddd319b-b0a7-4767-b1c4-66fe34bd63e4@github.com>

On Fri, 21 Oct 2022 15:26:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.39
> $ make clean build-hsdis
> 
> === Output from failing command(s) repeated here ===
> * For target support_hsdis_hsdis-binutils.o:

So what do we do with this? 
* Declare in building.md that we only support binutils prior to 2.39? 
* Sacrifice backwards compatibility if we build with binutils 2.39 or above? 
* Is there a third option?

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

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


From luhenry at openjdk.org  Tue Feb 14 11:13:44 2023
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 14 Feb 2023 11:13:44 GMT
Subject: RFR: 8295795: hsdis does not build with binutils 2.39+
In-Reply-To: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
References: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
Message-ID: <wiKfmcNPG-nsfinaaH9XsulrJBn6ms3HiSBB51tSBiU=.f5953eae-396e-4d6e-8380-dfb3a5fd2a68@github.com>

On Fri, 21 Oct 2022 15:26:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.39
> $ make clean build-hsdis
> 
> === Output from failing command(s) repeated here ===
> * For target support_hsdis_hsdis-binutils.o:

I'd go with sacrificing backward compatibility for multiple reasons:
1. It's an internal tool mostly targeted at Hotspot contributors (does this assumption holds true in your experience?). Some documentation and communication on the mailing list would help in the transition
2. Despite being annoying to build and distribute, binutils is still a reference implementation for tooling and has a support for a wide range of platforms.

I haven't looked how much breaking this compatibility is going to impact other hsdis implementations though (as-in will it require a change of API in hotspot <-> hsdis as well as hsdis <-> binutils/llvm/capstone

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

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


From ihse at openjdk.org  Tue Feb 14 11:22:47 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 14 Feb 2023 11:22:47 GMT
Subject: RFR: 8295795: hsdis does not build with binutils 2.39+
In-Reply-To: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
References: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
Message-ID: <LroE4i1A6uIfvvV6oE73Cj2Dj-qAd6stSSldYmyNm8k=.1446cbf6-d401-4aaf-9c0c-df65d29bc784@github.com>

On Fri, 21 Oct 2022 15:26:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.39
> $ make clean build-hsdis
> 
> === Output from failing command(s) repeated here ===
> * For target support_hsdis_hsdis-binutils.o:

Would the lack of backwards compatibility be helped by adding some kind of versioning coherence check to the hotspot/hsdis interface? 

I guess it will not help in this particular case -- as I understand it, the problem is that if we modify hsdis-binutils to support binutils 2.39, it will not be usable in older Hotspot versions. So it will not help if newer hsdis dlls flag themselves as "newer", since the older Hotspots will not be looking for that.

But it might help with future transitions, if we ever expect any such.

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

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


From ihse at openjdk.org  Tue Feb 14 11:27:43 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 14 Feb 2023 11:27:43 GMT
Subject: RFR: 8295795: hsdis does not build with binutils 2.39+
In-Reply-To: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
References: <o80LXEVHj7Lu90MgJHvqwXlx8uxzrJMewc6tFfOlx6o=.11412d16-8bcc-44b8-adbb-4e5b39092074@github.com>
Message-ID: <6aPCumMcJEyc7v69rdwev6gpMp9w45i9W9leTzGxpew=.c4af09f4-46e4-4440-9f56-3bc731304283@github.com>

On Fri, 21 Oct 2022 15:26:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ sh ./configure --with-boot-jdk=jdk19u-ea --with-hsdis=binutils --with-binutils-src=binutils-2.39
> $ make clean build-hsdis
> 
> === Output from failing command(s) repeated here ===
> * For target support_hsdis_hsdis-binutils.o:

What happens if we adopt the hsdis interface to match the new binutils, and we try to:
a) load a new hsdis into an old hotspot, or
b) load an old hsdis into a new hotspot?

Are we bound to just have incomprehensible crashes, or can we employ some tricks to at least be able to present an understandable error message to the user?

I could live with breaking compatibility if we output something like "This version of hsdis is too old" or "This version of Hotspot is too old". Creating a random and hard-to-debug crash dump due to method signature mismatches makes me much less keen on going down that route.

Otherwise I agree with you: I think that hsdis is usually used by a few select Hotspot developers, and that they hopefully build hsdis and hotspot together. But I also know there are a lot of guides out there in the wild, suggesting that you put hsdis.so somewhere on your lib path. I have no clue how common this is, but if people have done that, we can cause a lot of problem if this causes hard crashes with no good description with the problem.

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

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


From lucy at openjdk.org  Tue Feb 14 13:36:53 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 14 Feb 2023 13:36:53 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v4]
In-Reply-To: <TBk67ZnOXbatCT6A_QECLAfm1-DgbGVtkJrItNWI0E0=.5e48f116-24e2-4a63-9b8b-e59da7827123@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <TBk67ZnOXbatCT6A_QECLAfm1-DgbGVtkJrItNWI0E0=.5e48f116-24e2-4a63-9b8b-e59da7827123@github.com>
Message-ID: <1xf-Ljq9jJRVVJSUm5baYMHTN32bs4SeZsqIsqQLiLI=.aab334ae-a635-4e44-ba81-7cfae86e1406@github.com>

On Thu, 9 Feb 2023 10:21:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
>> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
>> On macOS, sysctlbyname can be used.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   link powrprof lib without pragma

Changes look good to me

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

Marked as reviewed by lucy (Reviewer).

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


From jwaters at openjdk.org  Tue Feb 14 14:42:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 Feb 2023 14:42:03 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
Message-ID: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>

Full details in linked entry, man did this give me a scare on my local branch

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

Commit messages:
 - toolchain.m4

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

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


From erikj at openjdk.org  Tue Feb 14 17:10:41 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 14 Feb 2023 17:10:41 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
Message-ID: <c8gRnx6tBBwaLxTo4oo0uNzOy78DbREWGeP1wVi-hLY=.accdcfc4-1318-4e7c-ac87-88cfb0549335@github.com>

On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Full details in linked entry, man did this give me a scare on my local branch
> 
> All C++ compilers for the build operating system are under the name c++ (when selected compiler is gcc), but when searching for BUILD_CXX the compiler given priority is an uppercase CC, and then g++, which is not correct since this simply links to the C compiler instead

I'm not sure I'm understanding the problem here. I think the uppercase `CC` is a remnant of Solaris support. In Solaris Studio, the C++ compiler is uppercase and the C compiler lowercase. What is this resolving to for you? Could it be that on a mac case insensitive file system it resolves to `cc` which in turn resolves to `clang`?  I'm not familiar with `c++` as a launcher, but I see on my local Linux host, this resolves to g++ and on my mac to clang++. The drawback of going with a standard launcher like this is that we have a harder time knowing which toolchain type it is. 

Dropping Solaris support for `CC` should be fine, but if we add `c++` it should probably be after `g++`. In the Solaris case, we wanted to be sure we got Solaris Studio and not GCC, but now I think we prefer the known `g++` over the potentially unknown `c++`.

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

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


From jcking at openjdk.org  Tue Feb 14 17:21:51 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 14 Feb 2023 17:21:51 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v4]
In-Reply-To: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
Message-ID: <tu0Bibed-p4HHbuAhtIEga8tVsufFcX85waXodx8brw=.54cfe985-5e43-4da2-9b60-ac5124401d8b@github.com>

> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.

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

  Update MSVC CFlags
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes: https://git.openjdk.org/jdk/pull/12073/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12073&range=03
  Stats: 13 lines in 1 file changed: 6 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12073.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12073/head:pull/12073

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


From ihse at openjdk.org  Tue Feb 14 17:27:42 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 14 Feb 2023 17:27:42 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
Message-ID: <PgcW3S6EofQfux-_E82CIh79wkGUucvK7QMLEVuUd-s=.79052ec2-cd47-4dd6-9b15-4748c5adc13e@github.com>

On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Full details in linked entry, man did this give me a scare on my local branch
> 
> All C++ compilers for the build operating system are under the name c++ (when selected compiler is gcc), but when searching for BUILD_CXX the compiler given priority is an uppercase CC, and then g++, which is not correct since this simply links to the C compiler instead

This do not affect macOS. The change is being made here:

if microsoft toolchain 
   ...
else 
   if macOS 
      ...
   else 
      .... <=== here
   endif
endif


So, in practice, it is for linux, but formally, everything that is not using the microsoft toolchain and is not running on macOS.

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

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


From ihse at openjdk.org  Tue Feb 14 17:31:40 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 14 Feb 2023 17:31:40 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
Message-ID: <euuYA00CFttXi2rbwArCnE96a_py2DZJhW_UOt5uqGY=.6b12cde3-13fd-4de7-a024-4ed02a0743ae@github.com>

On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Full details in linked entry, man did this give me a scare on my local branch
> 
> All C++ compilers for the build operating system are under the name c++ (when selected compiler is gcc), but when searching for BUILD_CXX the compiler given priority is an uppercase CC, and then g++, which is not correct since this simply links to the C compiler instead

Erik is probably right that this was created for Solaris, but using "CC" (in upper case) is afaik a long-standing Unix tradition. It is a bit hard too google, but see e.g. https://users.cs.cf.ac.uk/dave/C/node3.html#SECTION00312000000000000000. I think we should not remove it, but we might add other aliases, and we might discuss the order.

I agree with Erik that trying the g++ explicitly first is a good idea. I think we should keep CC, but it can be lower priority, so in that case the preferred order would be `g++ c++ CC`.

But I am also curious to what problem you experienced?

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

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


From jcking at openjdk.org  Tue Feb 14 18:22:29 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 14 Feb 2023 18:22:29 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v5]
In-Reply-To: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
Message-ID: <4MGNyOuj1HdQPSU8jpipuLTeFq_LHhJccMKeH8OLd0A=.63aedc93-33de-43af-91bd-c09921b6206a@github.com>

> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Remove -Ob3
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12073/files
  - new: https://git.openjdk.org/jdk/pull/12073/files/ec77cea3..3bc1f4bb

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

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

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


From jcking at openjdk.org  Tue Feb 14 18:22:34 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 14 Feb 2023 18:22:34 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v4]
In-Reply-To: <tu0Bibed-p4HHbuAhtIEga8tVsufFcX85waXodx8brw=.54cfe985-5e43-4da2-9b60-ac5124401d8b@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <tu0Bibed-p4HHbuAhtIEga8tVsufFcX85waXodx8brw=.54cfe985-5e43-4da2-9b60-ac5124401d8b@github.com>
Message-ID: <Jw5HLL02vPqsY7QNMNkHJXXOLZx4QPYZKIbjWKvGRf0=.2c7b69f2-1923-471f-ab58-1b60c2f14bc6@github.com>

On Tue, 14 Feb 2023 17:21:51 GMT, Justin King <jcking at openjdk.org> wrote:

>> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Update MSVC CFlags
>   
>   Signed-off-by: Justin King <jcking at google.com>

Okay, got my person box setup. It looks like -Ob3 will inflate the size. So that should be removed, unless performance is greatly improved. Doubtful.

However passing `-GR-` drops the size of the resulting executables, as expected. And using `-O2` doesn't seem to affect size all that much.

I'll continue to investigate.

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

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


From jcking at openjdk.org  Tue Feb 14 18:26:27 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 14 Feb 2023 18:26:27 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v6]
In-Reply-To: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
Message-ID: <XGtXFb-1sC9wW7LfHT3QOq-nLeDbkOOWC5LBVvVOZwQ=.8e22bf1a-b5b6-4ac7-8d0e-8c127811c862@github.com>

> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Add -Oy-
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12073/files
  - new: https://git.openjdk.org/jdk/pull/12073/files/3bc1f4bb..baaaa770

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

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

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


From jcking at openjdk.org  Tue Feb 14 18:31:16 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 14 Feb 2023 18:31:16 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v7]
In-Reply-To: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
Message-ID: <Y_Ufj73eDq1H9vzxQnPNTvOwXM7kmMWEP9sumRN3NVU=.cca2423d-354b-4334-abc6-483ba20b2f0e@github.com>

> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Reposition -Oy-
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12073/files
  - new: https://git.openjdk.org/jdk/pull/12073/files/baaaa770..b9a45523

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

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

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


From jcking at openjdk.org  Tue Feb 14 18:42:07 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 14 Feb 2023 18:42:07 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v8]
In-Reply-To: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
Message-ID: <5OeXmucpCCro-HxiPAS_D0kYrujO86MvkPyLMLOcCCg=.0dc35632-5973-476f-ac3d-a12888f1f442@github.com>

> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Reposition -Oy-
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12073/files
  - new: https://git.openjdk.org/jdk/pull/12073/files/b9a45523..bbb1d886

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

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

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


From jcking at openjdk.org  Tue Feb 14 19:01:47 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 14 Feb 2023 19:01:47 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v8]
In-Reply-To: <5OeXmucpCCro-HxiPAS_D0kYrujO86MvkPyLMLOcCCg=.0dc35632-5973-476f-ac3d-a12888f1f442@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <5OeXmucpCCro-HxiPAS_D0kYrujO86MvkPyLMLOcCCg=.0dc35632-5973-476f-ac3d-a12888f1f442@github.com>
Message-ID: <VesBEmrGAzB4KqZnC2S0YDc-TB9h79DD6xNYHDFLxf4=.44a2852c-62d1-4745-829d-c9cb94305d74@github.com>

On Tue, 14 Feb 2023 18:42:07 GMT, Justin King <jcking at openjdk.org> wrote:

>> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reposition -Oy-
>   
>   Signed-off-by: Justin King <jcking at google.com>

The main difference between `/O1` and `/O2`, besides speed vs. size, is that the latter adds `/Oi` which tells the compiler to try and inline intrinsics rather than making function calls. This can lead to improved speed. GCC/Clang do the same thing by treating certain functions like memcpy/memset/memmove and special.

Additionally I added `/Oy-` which preserves frame pointers. This makes MSVC match the GCC/Clang configuration with pass `-fno-omit-frame-pointer`.

Additionally we have disabled RTTI now by passing `/GR-`, this again matches GCC/Clang. The resulting size of the JVM binary drops by ~1MB.

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

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


From asotona at openjdk.org  Wed Feb 15 07:56:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 07:56:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <PXo9fJmIfK6sTlkbwWJuLz9kszQ1KSGu89wPLhMUuTw=.7ab33ee2-61a4-41c3-8038-4f97857cfc6a@github.com>

On Thu, 9 Feb 2023 12:54:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPool.java line 76:
> 
>> 74:      *              entry
>> 75:      */
>> 76:     BootstrapMethodEntry bootstrapMethodEntry(int index);
> 
> I note some inconsistency in naming - e.g. is `ByIndex` really needed, or a letfover to distinguish between different access modes (which are no longer there, it seems) ?

Yes, there are low-level use cases requiring to operate by index, for example javap.

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

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


From asotona at openjdk.org  Wed Feb 15 08:11:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 08:11:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <FsYcFKipqkTseekaQt-gHYX4NIlKc4im1XkfgyZJta4=.f3a496fc-8ec1-4f4c-b89b-449fb2c92f17@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <FsYcFKipqkTseekaQt-gHYX4NIlKc4im1XkfgyZJta4=.f3a496fc-8ec1-4f4c-b89b-449fb2c92f17@github.com>
Message-ID: <8KL3-QT9rm0VE6ceu07WBuNt_UHj2cGNumLRzazxCKM=.f6b60cc7-427d-4958-a3a1-2a31e925e9f1@github.com>

On Thu, 9 Feb 2023 13:01:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/ClassEntry.java line 80:
>> 
>>> 78:      * Return a List composed by appending the additions to the base list.
>>> 79:      * @param base The base elements for the list, must not include null
>>> 80:      * @param additions The ClassEntrys to add to the list, must not include null
>> 
>> Perhaps we should use `{@code}` or {@link}` to surround type names (here and elsewhere). `ClassEntrys` looks particularly odd :-)
>
> It is odd to see what is essentially a list append operation in here. IMHO, these helper methods, if needed (I couldn't find uses in the JDK), should probably be added to Collections (which probably means in the jdktypes package for now) - as I don't see anything really ClassEntry/ClassDesc specific about them.

I'll make a note to deeply review javadoc for types and to wrap them, thanks.

As for the List combining methods, they had been proposed, discussed and approved here:
https://github.com/openjdk/jdk-sandbox/pull/35
Feel free to re-open the discussion on mailing list, maybe we can address them better now.
However there is no general contract between "entries" and "symbols" yet, so such methods could be declared generic.

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

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


From asotona at openjdk.org  Wed Feb 15 08:22:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 08:22:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>

On Thu, 9 Feb 2023 14:01:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 537:
> 
>> 535:      * @param <T> the type of the entry
>> 536:      */
>> 537:     <T extends PoolEntry> T maybeClone(T entry);
> 
> This feels a more primitive operation than the name suggests. Have you considered making ConstantPool extend Consumer<PoolEntry> and call this "accept" ?

I'm not quite sure what exactly do you propose.
`ConstantPool` should not accept anything as it is read-only, so "accept" would be confusing.
`ConstantPoolBuilder::maybeClone` is rather a `Function`, where the name might be changed to `ConstantPoolBuilder::apply`.
However there are so many "accepts" and "applies" across the API, that reducing API verbosity to just these functional terms might significantly decrease readability.

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

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


From asotona at openjdk.org  Wed Feb 15 08:29:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 08:29:59 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <sl0obxW3t2tdKsfPz_nvmkaiLFlI94m267mFJ6Hmevo=.fb83703e-f78f-41b9-8f74-14f4d2a45bed@github.com>

On Thu, 9 Feb 2023 13:10:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 98:
> 
>> 96:     <T> T optionValue(Classfile.Option.Key option);
>> 97: 
>> 98:     boolean canWriteDirect(ConstantPool constantPool);
> 
> Missing javadoc in these two methods.

Will fix it, thanks.

> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 187:
> 
>> 185:      * {@return A {@link ModuleEntry} describing the module whose name
>> 186:      * is encoded in the provided {@linkplain Utf8Entry}}
>> 187:      * If a Module entry in the pool already describes this class,
> 
> (Here and elsewhere) - Module is capitalized. Either you use a lower case name, or you use a capital name, to refer to `ModuleEntry`, or `CONSTANT_Module_info` - e.g. a standalone `Module` with capital `M` is not a concept in this API. (personally I think lower case is just fine).

Will fix it, thanks.

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

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


From asotona at openjdk.org  Wed Feb 15 09:53:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 09:53:01 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <uwS4lAi9bPpXub-KbDvu2-VAsFDweNW0P7eYG-Ky0bg=.5c818fa2-5b79-4dc5-be71-8c3e965ab435@github.com>

On Thu, 9 Feb 2023 13:17:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 66:
> 
>> 64:      * @param <V> the type of the optional value
>> 65:      */
>> 66:     public sealed interface Option<V> permits Options.OptionValue {
> 
> After looking more at the usages of Options it is not clear to me as to why generics are needed. Lookup is always performed using a non-generic Option.Key - so the API code has to be unchecked anyway. In fact, I'm not even sure you need a `value()` method. When looking at usages, Option is mostly something you create when you need to pass it to something else (e.g. a constant pool, etc.). Since the client has created the option, it is not clear to me that the client has a need to access the option value (which the API implementation can access internally by other means).

You are right, I've tried to remove generics from `Option` and `Option::value` method and it didn't have any impact on any use case we have.
All access to the `Option` value is done through `ClassReader::optionValue` or `ConstantPoolBuilder::optionValue`, there was no use of `Option::value` at all.
I think it is valuable API cleanup, thanks!

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

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


From asotona at openjdk.org  Wed Feb 15 10:12:00 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 10:12:00 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v17]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <BImLG8Uet-vMhECdS5bPvUsZ1_Xcv_ntNqKra0-fHc0=.3876b159-e703-4142-a12c-5c547fa04c76@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - removed generics from Classfile.Option
 - Javadoc fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/ec6829e9..673887ab

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

  Stats: 78 lines in 10 files changed: 15 ins; 4 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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


From asotona at openjdk.org  Wed Feb 15 12:43:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 12:43:41 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v18]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <D2hQAGJG72OP1HAHHQ-EQZku4l6bkDgtaYHqzyxQjJA=.4f3eb47b-0d20-4358-943c-cccfac02a31d@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added missing factory methods to ModuleExportInfo and ModuleOpenInfo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/673887ab..bb295b53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=16-17

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

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


From jwaters at openjdk.org  Wed Feb 15 13:04:43 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 15 Feb 2023 13:04:43 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <c8gRnx6tBBwaLxTo4oo0uNzOy78DbREWGeP1wVi-hLY=.accdcfc4-1318-4e7c-ac87-88cfb0549335@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
 <c8gRnx6tBBwaLxTo4oo0uNzOy78DbREWGeP1wVi-hLY=.accdcfc4-1318-4e7c-ac87-88cfb0549335@github.com>
Message-ID: <RfZVcUsY4zFgk5WNLQCE_y8WI4-R3Pq7Cv-TswvYex4=.ba9f7ada-64c7-4d05-b5c3-bf1e38e8e523@github.com>

On Tue, 14 Feb 2023 17:07:13 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I'm not sure I'm understanding the problem here. I think the uppercase `CC` is a remnant of Solaris support. In Solaris Studio, the C++ compiler is uppercase and the C compiler lowercase. What is this resolving to for you? Could it be that on a mac case insensitive file system it resolves to `cc` which in turn resolves to `clang`? I'm not familiar with `c++` as a launcher, but I see on my local Linux host, this resolves to g++ and on my mac to clang++. The drawback of going with a standard launcher like this is that we have a harder time knowing which toolchain type it is.
> 
> Dropping Solaris support for `CC` should be fine, but if we add `c++` it should probably be after `g++`. In the Solaris case, we wanted to be sure we got Solaris Studio and not GCC, but now I think we prefer the known `g++` over the potentially unknown `c++`.

`c++` is indeed the alias of the C++ Compiler that is used for compiling C++ for the build platform, much like `cc` is for C. On my end, the uppercase `CC` ends up resolving to `gcc`, likely because `CC` doesn't exist (at least on some platforms), so the next best fallback of `cc` is chosen, which quite understandably makes the linker give up on life when compiling something like `adlc` which was written in C++



> Erik is probably right that this was created for Solaris, but using "CC" (in upper case) is afaik a long-standing Unix tradition. It is a bit hard too google, but see e.g. https://users.cs.cf.ac.uk/dave/C/node3.html#SECTION00312000000000000000. I think we should not remove it, but we might add other aliases, and we might discuss the order.
> 
> I agree with Erik that trying the g++ explicitly first is a good idea. I think we should keep CC, but it can be lower priority, so in that case the preferred order would be `g++ c++ CC`.
> 
> But I am also curious to what problem you experienced?

For one, when testing this on WSL and an Ubuntu VM, build tools written in C++ such as `adlc` started getting compiled as C, which turned out about as well as you might expect :P

I don't know about shifting the order that these are searched though, `cc` and `c++` are explicitly listed as the compilers meant for "this" platform (the one we are building on), which seems to be explicitly what we want here. Wouldn't searching for `g++` first (and correspondingly swapping `gcc` as the first search for C as well) risk returning the compiler for `--openjdk-target` as the build compiler? (I also had the worry that leaving `CC` as the last search would risk returning `gcc` if the build platform exhausts every other possible compiler and the uppercase `CC` is not present, but after some thought it sounds very unlikely to happen)

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

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


From asotona at openjdk.org  Wed Feb 15 14:12:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 14:12:13 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
Message-ID: <k1gsOcFRe-z6bT8ru55uLduJG3ZL1yW2bfFCtHCugxo=.700a49d0-df6e-4a15-866f-91dfbc5975c5@github.com>

On Thu, 9 Feb 2023 15:07:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/TypeCheckInstruction.java line 39:
> 
>> 37: 
>> 38: /**
>> 39:  * Models an {@code instanceof} or {@code checkcast} instruction in the {@code
> 
> This seems to model both `instanceof` and `checkcast`. The latter seems to overlap partially with `ConvertInstruction`.

`instanceof` and `checkcast` are both very similar type checking instructions. They have the same length, the same format, the same specification of the instruction parameters and almost the same behaviour.
All members of `ConvertInstruction` have no instruction parameters and source and target of conversion is identified from the opcode. Also the instructions do conversions and not type checking.
I don't see any averlap.

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

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


From ihse at openjdk.org  Wed Feb 15 14:13:08 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 15 Feb 2023 14:13:08 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <RfZVcUsY4zFgk5WNLQCE_y8WI4-R3Pq7Cv-TswvYex4=.ba9f7ada-64c7-4d05-b5c3-bf1e38e8e523@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
 <c8gRnx6tBBwaLxTo4oo0uNzOy78DbREWGeP1wVi-hLY=.accdcfc4-1318-4e7c-ac87-88cfb0549335@github.com>
 <RfZVcUsY4zFgk5WNLQCE_y8WI4-R3Pq7Cv-TswvYex4=.ba9f7ada-64c7-4d05-b5c3-bf1e38e8e523@github.com>
Message-ID: <e1x-QErvWtGtoHT8wq7dhlc4CCiYzjuLgR2_UmEa21A=.9032ba94-5b3e-47d2-9167-38b841090856@github.com>

On Wed, 15 Feb 2023 13:02:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> On my end, the uppercase `CC` ends up resolving to `gcc`, likely because `CC` doesn't exist (at least on some platforms)

I don't understand what you are saying here. Prior to you patch, we looked for exactly two executables: `CC` and `g++`, in that order. If an executable named `CC` was found in the PATH, we picked it, otherwise we looked for `g++`. If neither was found, configure would fail.

So then the question is: do you have `CC` on your path? 

You say "`CC` ends up resolving", but who is doing that resolving? Not the configure script, afaik. 

Is this, after all, some issue with case-insensitive file systems? Is this part of your attempt to get the JDK to build on Windows with a non-Microsoft toolchain? Does it mean that `cc` is found in the PATH, and that on Windows this is indistinguishable from `CC`?

Then this might still be something we want to change, but you need to rename, and rephrase, the bug report. What you want in that case is an adaptation for making a kind of cross between OS and toolchain that we do not support. I strongly suggest you keep all such changes in a separate, private branch, until you reach the point that you can actually get a JDK built, that passes a fair amount of testing. Then we can start discussing how up upstream the changes needed to do that build, if at all.

If you are experimenting like this, and find an issue that affects the existing build badly, then yes, we can fix that separately. Maybe it was your understanding that you had found such an issue, but if that is the case, I believe you are wrong.

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

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


From asotona at openjdk.org  Wed Feb 15 14:15:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 14:15:39 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
Message-ID: <bdK2KXUQ_Do6CM-DG67hB5boHppibz_pnKOXyAYMSs4=.026ecfa5-edd1-4865-b8dc-7fdbc897c416@github.com>

On Thu, 9 Feb 2023 14:24:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java line 63:
> 
>> 61:      * aload_0}).
>> 62:      */
>> 63:     sealed interface IntrinsicConstantInstruction extends ConstantInstruction
> 
> I'm not super sure of the fine-grained distinction here. The constant pool variant is interesting (as you can ask for the associated constant entry) - but the distinction between intrinsics vs. argument seems rather weak.

They significantly differ in instruction formats and instruction format distinction is critical for some use cases.

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

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


From asotona at openjdk.org  Wed Feb 15 14:27:28 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 14:27:28 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <scAqAuD2wQBhQdg_N1e5PPRJkmhwgCW-Mp__BajTxsw=.c73a8812-926e-4bf0-8e8f-7589a809b173@github.com>
Message-ID: <PXzUXkDRw2F23g7ctTgVM7B_mXkSFoz_qpSPF_TEm84=.c09e2fcd-066f-4d96-9d0a-0d7f6320326e@github.com>

On Thu, 9 Feb 2023 14:18:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java line 47:
> 
>> 45:      * {@return the start of the instruction range}
>> 46:      */
>> 47:     Label startScope();
> 
> I noticed that this pattern of start/endScope is here, but also in ExceptionCatch, LocalVariable and LocalVariableType. Consider using a common interface for "instructions that are associated with a range".

That is interesting RFE, thanks.

> src/java.base/share/classes/jdk/internal/classfile/instruction/InvokeInstruction.java line 60:
> 
>> 58:      * {@return whether the class holding the method is an interface}
>> 59:      */
>> 60:     boolean isInterface();
> 
> This can also be tested with pattern matching on the MemberRefEntry?

Unfortunately the distinction is dynamic. As of my imagination pattern matching is not the best to model interface distinction of `InvokeInstruction`.

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

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


From asotona at openjdk.org  Wed Feb 15 14:48:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 14:48:23 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <AlXHJrPQTNZLumUXhMQevc7Yk51W4pvWDsarWCe-NmU=.3c2573c2-03eb-43f2-9b85-ce607695208d@github.com>

On Thu, 9 Feb 2023 14:04:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 62:
> 
>> 60:      * {@return whether this member is a method}
>> 61:      */
>> 62:     boolean isMethod();
> 
> this seems surprising - after all we have separate types for methods/fields.

I'll look at it - if still needed or just a relic.

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

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


From asotona at openjdk.org  Wed Feb 15 15:22:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 15:22:25 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <AlXHJrPQTNZLumUXhMQevc7Yk51W4pvWDsarWCe-NmU=.3c2573c2-03eb-43f2-9b85-ce607695208d@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <AlXHJrPQTNZLumUXhMQevc7Yk51W4pvWDsarWCe-NmU=.3c2573c2-03eb-43f2-9b85-ce607695208d@github.com>
Message-ID: <0cxv9q54041aXExLC6lQgy5m4tsIRIA51x4OLx-dBdk=.b799739b-d6dc-4a94-9d46-dd3167f2f36c@github.com>

On Wed, 15 Feb 2023 14:45:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 62:
>> 
>>> 60:      * {@return whether this member is a method}
>>> 61:      */
>>> 62:     boolean isMethod();
>> 
>> this seems surprising - after all we have separate types for methods/fields.
>
> I'll look at it - if still needed or just a relic.

Yes, it is possible to remove this method completely.

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

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


From asotona at openjdk.org  Wed Feb 15 15:25:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 15:25:41 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <JFTVXJrIyV4JzpvC7Qxa6Qo19lPc3DppvCFNY4J8L_E=.02fd2bcd-a751-4ca3-ad36-0a43f1e5a0c4@github.com>

On Thu, 9 Feb 2023 14:05:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/MemberRefEntry.java line 67:
> 
>> 65:      * {@return whether this member is an interface method}
>> 66:      */
>> 67:     boolean isInterface();
> 
> I'd prefer to see this to `MethodRefEntry`. But again, there's an entry for interface methods, so not sure how much this is needed.

The same as above, it is possible to remove it and the two use cases (in `ConcreteMethodHandleEntry::asSymbol` and `ClassPrinterImpl`) replace with `instanceof InterfaceMethodRefEntry`.
Thanks!

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

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


From asotona at openjdk.org  Wed Feb 15 15:31:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 15 Feb 2023 15:31:24 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v19]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <4tbi7L_lSPBugs7uv61dd44v7FWSARbLmu6CTocvytY=.51b7da25-81d1-4944-b297-29ef9ab36795@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removal of MemberRefEntry::isMethod and ::isInterface

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/bb295b53..dbb9e46a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=17-18

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

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


From jwaters at openjdk.org  Wed Feb 15 15:35:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 15 Feb 2023 15:35:13 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <e1x-QErvWtGtoHT8wq7dhlc4CCiYzjuLgR2_UmEa21A=.9032ba94-5b3e-47d2-9167-38b841090856@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
 <c8gRnx6tBBwaLxTo4oo0uNzOy78DbREWGeP1wVi-hLY=.accdcfc4-1318-4e7c-ac87-88cfb0549335@github.com>
 <RfZVcUsY4zFgk5WNLQCE_y8WI4-R3Pq7Cv-TswvYex4=.ba9f7ada-64c7-4d05-b5c3-bf1e38e8e523@github.com>
 <e1x-QErvWtGtoHT8wq7dhlc4CCiYzjuLgR2_UmEa21A=.9032ba94-5b3e-47d2-9167-38b841090856@github.com>
Message-ID: <QjW4Rsf8GK7jSNfsesvU8bjRuAXP2I0DEEUDogGS0DA=.e4f7b688-1242-4cf1-a041-9f8650d751d3@github.com>

On Wed, 15 Feb 2023 14:10:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Is this part of your attempt to get the JDK to build on Windows with a non-Microsoft toolchain? Does it mean that `cc` is found in the PATH, and that on Windows this is indistinguishable from `CC`?

No, not at all. I don't cross compile on that experimental branch, so this isn't an issue for me there

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

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


From ihse at openjdk.org  Wed Feb 15 15:41:30 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 15 Feb 2023 15:41:30 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
Message-ID: <lui1fCHAyyP3VfFX5Z53vH7s5p1SDpqZZIiV516sPmk=.c2126032-8f85-4628-82a1-e5e804c93536@github.com>

On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Full details in linked entry, man did this give me a scare on my local branch
> 
> All C++ compilers for the build operating system are under the name c++ (when selected compiler is gcc), but when searching for BUILD_CXX the compiler given priority is an uppercase CC, and then g++, which is not correct since this simply links to the C compiler instead

But that still leaves my question unanswered: So then the question is: do you have CC on your path? You say "CC ends up resolving", but who is doing that resolving?

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

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


From mbaesken at openjdk.org  Wed Feb 15 17:55:44 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 15 Feb 2023 17:55:44 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v4]
In-Reply-To: <TBk67ZnOXbatCT6A_QECLAfm1-DgbGVtkJrItNWI0E0=.5e48f116-24e2-4a63-9b8b-e59da7827123@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <TBk67ZnOXbatCT6A_QECLAfm1-DgbGVtkJrItNWI0E0=.5e48f116-24e2-4a63-9b8b-e59da7827123@github.com>
Message-ID: <4LKg5LooQj12WBy_PKAePe4CJHboR1c94pYqO-MO3BA=.85038975-6d5f-45db-83f5-7f2f57dc67d9@github.com>

On Thu, 9 Feb 2023 10:21:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
>> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
>> On macOS, sysctlbyname can be used.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   link powrprof lib without pragma

Hi David are you okay with the latest version ?

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

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


From jcking at openjdk.org  Wed Feb 15 18:01:26 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 15 Feb 2023 18:01:26 GMT
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++
Message-ID: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>

Update build-related infrastructure to support building with ASan under Microsoft Visual C++.

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

Commit messages:
 - Move comment to appropriate location
 - Use elif instead of separate if
 - Only pass -fsanitize=address to linker for Clang/GCC
 - Update asan_default_options.c with MSVC-specific extensions
 - Support using ASan with MSVC

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

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


From erikj at openjdk.org  Wed Feb 15 18:30:42 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 15 Feb 2023 18:30:42 GMT
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++
In-Reply-To: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
Message-ID: <0heKgQf67omFYCROSjkWsADDnaZXVC90CaAcmNY0bEM=.2b6b48be-f3aa-47dc-b96b-730e55640ee0@github.com>

On Wed, 15 Feb 2023 17:53:49 GMT, Justin King <jcking at openjdk.org> wrote:

> Update build-related infrastructure to support building with ASan under Microsoft Visual C++.

Build part looks ok.

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

Marked as reviewed by erikj (Reviewer).

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


From jcking at openjdk.org  Wed Feb 15 21:21:47 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 15 Feb 2023 21:21:47 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v9]
In-Reply-To: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
Message-ID: <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>

> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Revert usage of /GR-
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12073/files
  - new: https://git.openjdk.org/jdk/pull/12073/files/bbb1d886..53a2ef3a

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

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

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


From jcking at openjdk.org  Wed Feb 15 21:21:51 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 15 Feb 2023 21:21:51 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v8]
In-Reply-To: <5OeXmucpCCro-HxiPAS_D0kYrujO86MvkPyLMLOcCCg=.0dc35632-5973-476f-ac3d-a12888f1f442@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <5OeXmucpCCro-HxiPAS_D0kYrujO86MvkPyLMLOcCCg=.0dc35632-5973-476f-ac3d-a12888f1f442@github.com>
Message-ID: <ijur_KYt7uS6BTjxvwUNPodWKTx1cPVnuL91MChXkF8=.225b5a85-0f29-438d-b28c-bf2166c551cc@github.com>

On Tue, 14 Feb 2023 18:42:07 GMT, Justin King <jcking at openjdk.org> wrote:

>> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reposition -Oy-
>   
>   Signed-off-by: Justin King <jcking at google.com>

Looks like serviceability might rely on RTTI on Windows. Removed the addition of `/GR-`, which is unfortunate but necessary if serviceability relies on it.

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

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


From dholmes at openjdk.org  Thu Feb 16 02:08:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Feb 2023 02:08:57 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v8]
In-Reply-To: <ijur_KYt7uS6BTjxvwUNPodWKTx1cPVnuL91MChXkF8=.225b5a85-0f29-438d-b28c-bf2166c551cc@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <5OeXmucpCCro-HxiPAS_D0kYrujO86MvkPyLMLOcCCg=.0dc35632-5973-476f-ac3d-a12888f1f442@github.com>
 <ijur_KYt7uS6BTjxvwUNPodWKTx1cPVnuL91MChXkF8=.225b5a85-0f29-438d-b28c-bf2166c551cc@github.com>
Message-ID: <qCUi6iqjPK8MnlOLh76Z7UllsR6jUssLGaU4qUgO4d0=.0a2a0940-b6d6-4dd3-9608-29574acf9f5c@github.com>

On Wed, 15 Feb 2023 21:17:45 GMT, Justin King <jcking at openjdk.org> wrote:

> Looks like serviceability might rely on RTTI on Windows.

Can you point to the code please? We should not be using RTTI.

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

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


From dholmes at openjdk.org  Thu Feb 16 02:35:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Feb 2023 02:35:00 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v4]
In-Reply-To: <4LKg5LooQj12WBy_PKAePe4CJHboR1c94pYqO-MO3BA=.85038975-6d5f-45db-83f5-7f2f57dc67d9@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <TBk67ZnOXbatCT6A_QECLAfm1-DgbGVtkJrItNWI0E0=.5e48f116-24e2-4a63-9b8b-e59da7827123@github.com>
 <4LKg5LooQj12WBy_PKAePe4CJHboR1c94pYqO-MO3BA=.85038975-6d5f-45db-83f5-7f2f57dc67d9@github.com>
Message-ID: <bb0whcz8dZ7CxYAz92Xtr47dJHgPB5OjUHzYbdHT7S4=.da35623a-393d-42a4-a6c4-7254e55aa6da@github.com>

On Wed, 15 Feb 2023 17:53:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi David are you okay with the latest version ?

I thought you were looking at reducing the output:

> Maybe it makes sense to print the current idle state separately for all processors and if possible, output the other values just once .

I don't think idle states are particularly useful, so I'd prefer to see similar output to non-Windows rather than per-processor info that is the same for everything of interest.

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

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


From jcking at openjdk.org  Thu Feb 16 03:33:08 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 16 Feb 2023 03:33:08 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v8]
In-Reply-To: <qCUi6iqjPK8MnlOLh76Z7UllsR6jUssLGaU4qUgO4d0=.0a2a0940-b6d6-4dd3-9608-29574acf9f5c@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <5OeXmucpCCro-HxiPAS_D0kYrujO86MvkPyLMLOcCCg=.0dc35632-5973-476f-ac3d-a12888f1f442@github.com>
 <ijur_KYt7uS6BTjxvwUNPodWKTx1cPVnuL91MChXkF8=.225b5a85-0f29-438d-b28c-bf2166c551cc@github.com>
 <qCUi6iqjPK8MnlOLh76Z7UllsR6jUssLGaU4qUgO4d0=.0a2a0940-b6d6-4dd3-9608-29574acf9f5c@github.com>
Message-ID: <b0RrfCKn04yyC0q1tCPL2ASr-smy52VuBUnFA2lCgDs=.93a6c114-d992-427e-a955-c07531297f6b@github.com>

On Thu, 16 Feb 2023 02:03:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Looks like serviceability might rely on RTTI on Windows.
> 
> Can you point to the code please? We should not be using RTTI.

Removing /GR- makes the tests pass. I think somewhere we are indirectly relying on RTTI for Windows. Maybe related to DbgEng or DbgHelp on Windows. I'll have to look more to find it. It's only some of the tests.

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

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


From dholmes at openjdk.org  Thu Feb 16 04:02:59 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Feb 2023 04:02:59 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v9]
In-Reply-To: <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>
Message-ID: <HVJ0Y-A4kOwcinvz4wGYmYSCn_C2dqHgSfvgOcbne7M=.138539ef-8f5c-414f-80a2-4f7d8464887f@github.com>

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

>> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert usage of /GR-
>   
>   Signed-off-by: Justin King <jcking at google.com>

I grepp'd the tests and couldn't find anything that appears to be RTTI usage: no dynamic_cast, typeid or type_info. That said use of RTTI in tests is a different matter - tests can use whatever language facilities they need.

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

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


From jcking at openjdk.org  Thu Feb 16 04:23:42 2023
From: jcking at openjdk.org (Justin King)
Date: Thu, 16 Feb 2023 04:23:42 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v9]
In-Reply-To: <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>
Message-ID: <gMgq4nGGq-oCSj7GzSzh-PrSWid9ad_ZeGfHLfLPmCQ=.2f6de3be-22c5-4eb1-8b20-fa2b6666d11e@github.com>

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

>> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert usage of /GR-
>   
>   Signed-off-by: Justin King <jcking at google.com>

Disabling RTTI seems to prevent serviceability from locating threads on Windows. As the test that failed isn't printing threads at all. My current hypothesis is MSVC isn't exporting some symbols now that RTTI is disabled, and either DbgHelp or DbgEng needs it.  I'll see if I can track it down.

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

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


From jwaters at openjdk.org  Thu Feb 16 05:04:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Feb 2023 05:04:27 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <lui1fCHAyyP3VfFX5Z53vH7s5p1SDpqZZIiV516sPmk=.c2126032-8f85-4628-82a1-e5e804c93536@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
 <lui1fCHAyyP3VfFX5Z53vH7s5p1SDpqZZIiV516sPmk=.c2126032-8f85-4628-82a1-e5e804c93536@github.com>
Message-ID: <aYUWKX6yghYzxas3zB8pR034vm3fqmVGjVWkgBKwiRI=.9ca4f734-e36d-4228-8c37-999bb60ab3e8@github.com>

On Wed, 15 Feb 2023 15:38:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> But that still leaves my question unanswered: So then the question is: do you have CC on your path? You say "CC ends up resolving", but who is doing that resolving?

I just checked on my WSL install and not only is `CC` not in the path, it doesn't seem like `CC` is anywhere to be found in the first place. When configure asks for something named `CC`, it's likely the shell itself used in the build finding the lowercase `cc` in the path instead after not being able to find the uppercase version and calling it a day, to answer the question of what is returning the build compiler to be used. You're probably right that it should have a lower priority than fully removed, but I'm not so sure about the priorities `c++` and `g++` should take, as proposed (`g++ c++ CC` as opposed to `c++ g++ CC`)

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

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


From iklam at openjdk.org  Thu Feb 16 06:35:27 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Feb 2023 06:35:27 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v9]
In-Reply-To: <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>
Message-ID: <dSZuIK87NesGqJR5ZjDArPXTvd1-9gEuX8JjVYyzmgg=.761b9936-5b15-4772-bebd-300e75e066fb@github.com>

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

>> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert usage of /GR-
>   
>   Signed-off-by: Justin King <jcking at google.com>

As a general comment, the bug title should be to the point. "Look suspicious" contains no information. It looks like you are changing the optimization level, so the bug title should reflect that.

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

Changes requested by iklam (Reviewer).

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


From mbaesken at openjdk.org  Thu Feb 16 09:18:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 16 Feb 2023 09:18:58 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v5]
In-Reply-To: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
Message-ID: <QlSM_3RkD1KaachnGP-PFNJKqSg45GZ1L4qZl0s_19c=.dac73c44-d43d-4349-b423-172318b3962d@github.com>

> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
> On macOS, sysctlbyname can be used.

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

  Do not print idle state infos on Windows, print same MHz values for all proces only once

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12403/files
  - new: https://git.openjdk.org/jdk/pull/12403/files/9a311018..2811225e

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

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

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


From asotona at openjdk.org  Thu Feb 16 09:42:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Feb 2023 09:42:43 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <6gCIlUafIspeaYjIs6AlFuRqJtUsuOqjKOSDBs8kYV4=.14b51d52-5b74-4918-a3ab-a7fda35a723b@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <6gCIlUafIspeaYjIs6AlFuRqJtUsuOqjKOSDBs8kYV4=.14b51d52-5b74-4918-a3ab-a7fda35a723b@github.com>
Message-ID: <EWWS88WJjgidmXnYYHv-wKa-U1ufSPKcDvJT8hMyxI8=.40faf7c6-daa7-44cf-9d07-f1bcceb4131b@github.com>

On Fri, 10 Feb 2023 11:16:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/Utf8Entry.java line 47:
>> 
>>> 45:      * @param s the string to compare to
>>> 46:      */
>>> 47:     boolean equalsString(String s);
>> 
>> Whatif the provided string contains character that are not representable in Utf8? Should we throw (e.g. `IllegalArgumentException`) ?
>
> I would rather expect `false` value returned, however this case is probably not covered by tests.

You almost got me, I had to think about it for a while :) 
Any String is always representable in Utf8 (or modified Utf8 used in classfile).
It is completely valid to store even 4-byte Unicode characters in Utf8Entry and match them with (Utf16 encoded) String. I'll add such String to the existing test.

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

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


From ihse at openjdk.org  Thu Feb 16 10:04:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 16 Feb 2023 10:04:25 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
Message-ID: <3K4ziAT7OZKnTbNdNKgDJEryvb_kv8rESyxCzSFKsNQ=.1fa92e2c-5116-4998-af9d-b6c8b2089b44@github.com>

On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Full details in linked entry, man did this give me a scare on my local branch
> 
> All C++ compilers for the build operating system are under the name c++ (when selected compiler is gcc), but when searching for BUILD_CXX the compiler given priority is an uppercase CC, and then g++, which is not correct since this simply links to the C compiler instead

We always try to find a more specific tool first, then fall back to a more generic. So `g++` should be checked before `c++`, since we know we will get gcc in the first case, but not the second.

If we search for `CC` in the path but finds `cc`, then there is a bug in how `UTIL_REQUIRE_PROGS` looks up stuff in the path. Feel free to investigate and/or fix.

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

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


From mcimadamore at openjdk.org  Thu Feb 16 10:27:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 10:27:44 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
Message-ID: <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>

On Wed, 15 Feb 2023 08:20:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 537:
>> 
>>> 535:      * @param <T> the type of the entry
>>> 536:      */
>>> 537:     <T extends PoolEntry> T maybeClone(T entry);
>> 
>> This feels a more primitive operation than the name suggests. Have you considered making ConstantPool extend Consumer<PoolEntry> and call this "accept" ?
>
> I'm not quite sure what exactly do you propose.
> `ConstantPool` should not accept anything as it is read-only, so "accept" would be confusing.
> `ConstantPoolBuilder::maybeClone` is rather a `Function`, where the name might be changed to `ConstantPoolBuilder::apply`.
> However there are so many "accepts" and "applies" across the API, that reducing API verbosity to just these functional terms might significantly decrease readability.

As I read the javadoc (I have not looked at impl yet), this method can effectively be used to add an entry to the constant pool (if the entry does not yet exist - in which case existing entry is returned).

After having looked at the implementation a bit, I think my assumption is correct - e.g. when calling `getfield` on a code builder, the FieldRef passed to the code builder is added to the constant pool using `maybeClone`.

So, in my mind at least, this `maybeClone` is the main avenue by which new constant pool entries are added. In builders we have a `with` method - I think a `with` method would also be ok here, given what the method does (ok, there is the wrinkle that, if the entry already exists it is not added, but that seems more of an optimization to avoid duplicates).

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

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


From asotona at openjdk.org  Thu Feb 16 10:41:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Feb 2023 10:41:33 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added 4-byte Unicode text to Utf8EntryTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/dbb9e46a..7a45ebd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=18-19

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

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


From asotona at openjdk.org  Thu Feb 16 10:51:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Feb 2023 10:51:42 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
 <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>
Message-ID: <3HZ_jmmtzk1RUgiUGwGudTaqvzEbFkla14T4EDKSjxU=.1fd22057-627c-42df-80a1-1c7c37486c4c@github.com>

On Thu, 16 Feb 2023 10:25:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I'm not quite sure what exactly do you propose.
>> `ConstantPool` should not accept anything as it is read-only, so "accept" would be confusing.
>> `ConstantPoolBuilder::maybeClone` is rather a `Function`, where the name might be changed to `ConstantPoolBuilder::apply`.
>> However there are so many "accepts" and "applies" across the API, that reducing API verbosity to just these functional terms might significantly decrease readability.
>
> As I read the javadoc (I have not looked at impl yet), this method can effectively be used to add an entry to the constant pool (if the entry does not yet exist - in which case existing entry is returned).
> 
> After having looked at the implementation a bit, I think my assumption is correct - e.g. when calling `getfield` on a code builder, the FieldRef passed to the code builder is added to the constant pool using `maybeClone`.
> 
> So, in my mind at least, this `maybeClone` is the main avenue by which new constant pool entries are added. In builders we have a `with` method - I think a `with` method would also be ok here, given what the method does (ok, there is the wrinkle that, if the entry already exists it is not added, but that seems more of an optimization to avoid duplicates).

The main difference is that if the given entry is not directly applicable (when it comes from 3rd constant pool or when the pool is not shared during transformation) - a new or matching entry to the target pool is returned.
This is not a builder pattern, this is projection of an entry to the target CP and it also prevents duplicates.

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

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


From asotona at openjdk.org  Thu Feb 16 10:51:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 16 Feb 2023 10:51:42 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <3HZ_jmmtzk1RUgiUGwGudTaqvzEbFkla14T4EDKSjxU=.1fd22057-627c-42df-80a1-1c7c37486c4c@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
 <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>
 <3HZ_jmmtzk1RUgiUGwGudTaqvzEbFkla14T4EDKSjxU=.1fd22057-627c-42df-80a1-1c7c37486c4c@github.com>
Message-ID: <AJgsunTEzUuzgdTQKiSBTXDrhs5_MmqNZWnSURk61AE=.b8e71cb6-1ccb-49f3-afda-d2a98f4ec701@github.com>

On Thu, 16 Feb 2023 10:46:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> As I read the javadoc (I have not looked at impl yet), this method can effectively be used to add an entry to the constant pool (if the entry does not yet exist - in which case existing entry is returned).
>> 
>> After having looked at the implementation a bit, I think my assumption is correct - e.g. when calling `getfield` on a code builder, the FieldRef passed to the code builder is added to the constant pool using `maybeClone`.
>> 
>> So, in my mind at least, this `maybeClone` is the main avenue by which new constant pool entries are added. In builders we have a `with` method - I think a `with` method would also be ok here, given what the method does (ok, there is the wrinkle that, if the entry already exists it is not added, but that seems more of an optimization to avoid duplicates).
>
> The main difference is that if the given entry is not directly applicable (when it comes from 3rd constant pool or when the pool is not shared during transformation) - a new or matching entry to the target pool is returned.
> This is not a builder pattern, this is projection of an entry to the target CP and it also prevents duplicates.

`maybeClone` is not the main avenue, it is rather a helper method and I'll look at details if it is necessary too expose it.

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

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


From stuefe at openjdk.org  Thu Feb 16 11:04:27 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Feb 2023 11:04:27 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
Message-ID: <td_LmSgvuTEg9rpWjYte-xUuDcdFyC3bU_ABUYw92aI=.0beb850e-1a36-46c5-b183-5559f9fb8eed@github.com>

On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Full details in linked entry, man did this give me a scare on my local branch
> 
> All C++ compilers for the build operating system are under the name c++ (when selected compiler is gcc), but when searching for BUILD_CXX the compiler given priority is an uppercase CC, and then g++, which is not correct since this simply links to the C compiler instead

Can we please give this issue a clear name that makes sense, and a better text? What is "dangerously wrong"? For the casual reader, this issue and its description are pretty opaque.

This makes it also difficult for backporters to evaluate whether this change needs immediate attention.

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

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


From ihse at openjdk.org  Thu Feb 16 11:18:29 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 16 Feb 2023 11:18:29 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
Message-ID: <Znh9vyCDJlC_Y_XyNTQMmVLjdWR1FYwKNfo890HKf2c=.0e447246-77af-4443-ab9c-b9c2cbe15be1@github.com>

On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Full details in linked entry, man did this give me a scare on my local branch
> 
> All C++ compilers for the build operating system are under the name c++ (when selected compiler is gcc), but when searching for BUILD_CXX the compiler given priority is an uppercase CC, and then g++, which is not correct since this simply links to the C compiler instead

I agree. The current title sounds needlessly alarmist.

We're still trying to figure out what changes are suggested, or needed. It sounds like this is about two issues:

1) Change the order in which we look for build C++ compiler
2) On platforms with case-insensitive file systems (like Windows), UTIL_LOOKUP_PROGS is possibly doing the wrong thing

@TheShermanTanker If you agree with this analysis, perhaps the best way forward is to close this PR and the associated bug, and open two new separate bugs?

And if not, you need to be clear what you think the problem is that will not be solved by fixing these two issues.

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

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


From mcimadamore at openjdk.org  Thu Feb 16 11:38:57 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 11:38:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
Message-ID: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>

On Thu, 16 Feb 2023 10:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added 4-byte Unicode text to Utf8EntryTest

src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 93:

> 91:          * @return name of the node
> 92:          */
> 93:         public ConstantDesc name();

Not sure about the ConstantDesc here. Why is it better than String?

src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 105:

> 103:          * @param out consumer of the printed fragments
> 104:          */
> 105:         default public void toJson(Consumer<String> out) {

there are some `public` modifiers here which can be omitted

src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 140:

> 138: 
> 139:     /**
> 140:      * A tree node holding {@link List} of nested nodes.

It would perhaps be beneficial to have little examples of what these different nodes are used for. I had to look at `ClassPrinterImpl` to get some idea.

src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 93:

> 91: 
> 92: /**
> 93:  * ClassRemapper is a {@link jdk.internal.classfile.ClassTransform}, {@link jdk.internal.classfile.FieldTransform},

Maybe wrap occurrences of `ClassRemapper` with `{@code}` (here and elsewhere)

src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 168:

> 166:         public void accept(ClassBuilder clb, ClassElement cle) {
> 167:             switch (cle) {
> 168:                 case FieldModel fm ->

What about NestMembers, NestHost, PermittedSubclasses (and probably others) ?

src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 306:

> 304: 
> 305:         ClassSignature mapClassSignature(ClassSignature signature) {
> 306:             return ClassSignature.of(signature.typeParameters(),

Should type parameters also be mapped? (as they might have class bounds). Both here and in `mapMethodSignature`.

src/java.base/share/classes/jdk/internal/classfile/components/CodeLocalsShifter.java line 43:

> 41: 
> 42: /**
> 43:  * CodeLocalsShifter is a {@link jdk.internal.classfile.CodeTransform} shifting locals to

Missing `{@code}` (here and elsewhere)

src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java line 43:

> 41: 
> 42: /**
> 43:  * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurences

Suggestion:

 * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurrences

src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 43:

> 41: 
> 42: /**
> 43:  * CodeStackTracker is a {@link jdk.internal.classfile.CodeTransform} synchronously tracking

Not sure what is meant by `synchronously`

src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 53:

> 51:  *         trackedBuilder.aload(0);
> 52:  *         trackedBuilder.lconst_0();
> 53:  *         trackedBuilder.ifThen(...

missing closed parens?

src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 77:

> 75:       *
> 76:       * Temporary unknown stack content can be recovered by binding of a {@linkplain Label} used as
> 77:       * target of a branch instruction from existing code with known Stack (forward branch target),

Suggestion:

      * target of a branch instruction from existing code with known stack (forward branch target),

src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 86:

> 84:     /**
> 85:       * Returns tracked max stack size.
> 86:       * Returns an empty {@linkplain Optional} when Max stack size tracking has been lost.

Suggestion:

      * Returns an empty {@linkplain Optional} when max stack size tracking has been lost.

src/java.base/share/classes/jdk/internal/classfile/components/package-info.java line 97:

> 95:  * {@snippet lang="java" class="PackageSnippets" region="classInstrumentation"}
> 96:  */
> 97: package jdk.internal.classfile.components;

watch out for newline

src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 563:

> 561:                       list("attributes", "attribute", clm.attributes().stream().map(Attribute::attributeName)))
> 562:                 .with(constantPoolToTree(clm.constantPool(), verbosity))
> 563:                 .with(attributesToTree(clm.attributes(), verbosity))

Is this ok? It seems we also add class attributes in the map node (see "attributes" map node).

src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 745:

> 743:                     list("stack", "item", Stream.of())));
> 744:             }
> 745:             var excHandlers = com.exceptionHandlers().stream().map(exc -> new ExceptionHandler(com.labelToBci(exc.tryStart()), com.labelToBci(exc.tryEnd()), com.labelToBci(exc.handler()), exc.catchType().map(ct -> ct.name().stringValue()).orElse(null))).toList();

Watch out for very long lines

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

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


From mcimadamore at openjdk.org  Thu Feb 16 11:38:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 11:38:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <oYaLdiYyDVuK_MQipb_p3HpgH_p6xBZByVeG33jPYps=.2282798d-f696-4139-88a5-bbf0f3274ac5@github.com>

On Thu, 16 Feb 2023 11:27:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java line 43:
> 
>> 41: 
>> 42: /**
>> 43:  * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurences
> 
> Suggestion:
> 
>  * CodeRelabeler is a {@link jdk.internal.classfile.CodeTransform} replacing all occurrences

Might want to use `{@code}` (here and elsewhere)

> src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 43:
> 
>> 41: 
>> 42: /**
>> 43:  * CodeStackTracker is a {@link jdk.internal.classfile.CodeTransform} synchronously tracking
> 
> Not sure what is meant by `synchronously`

Might want to use `{@code}` (here and elsewhere)

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

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


From duke at openjdk.org  Thu Feb 16 12:18:44 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 16 Feb 2023 12:18:44 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
Message-ID: <XdPsRS7sN9MC3gcIyTcIN3BhhfrgSjSZYnq1jC_pqc0=.aad91048-53be-4f19-a7fd-ed4e41ad5deb@github.com>

On Thu, 16 Feb 2023 10:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added 4-byte Unicode text to Utf8EntryTest

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 96:

> 94:      * @param <T> the type of the option value
> 95:      */
> 96:     <T> T optionValue(Classfile.Option.Key option);

This unconstrained type parameter will result in and implicit conversion to any type that the caller assigns it to, which might result in a `ClassCastException` if the caller gets the type wrong.

Is that intentional?

Alternative solutions: 

* Convert `Key` to an ordinary class or sealed interface, and add a type parameter to it, for the value type.
* Add a parameter the the method of type `Class<T>`.

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

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


From mcimadamore at openjdk.org  Thu Feb 16 12:58:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 12:58:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
Message-ID: <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>

On Thu, 16 Feb 2023 10:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added 4-byte Unicode text to Utf8EntryTest

src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java line 49:

> 47:  * BoundAttribute
> 48:  */
> 49: public abstract sealed class BoundAttribute<T extends Attribute<T>>

Understanding checkpoint: there are two variant of most of the elements: an *unbound* form and a *bound* form. The former is what you get by constructing the element from scratch using a factory. The latter is what you get when the element is read from the classfile.

Since bound elements have a reference to real "bytes" in some classfile, this distinction allows the implementation to speed up the writing of the element contents to the class buffer - that is, writing an unbound element goes through a "slow path" which involves constant pool entry creation, etc. For bound elements, we can, at least in some cases (e.g. when the builder supports direct writing) just copy the underlying bytes to the target buffer.

src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 30:

> 28:  * An open-chain multimap used to map nonzero hashes to indexes (of either CP
> 29:  * elements or BSM entries).  Code transformed from public domain implementation
> 30:  * (http://java-performance.info/implementing-world-fastest-java-int-to-int-hash-map/).

Could not open this link - seems to redirect to main page

src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 192:

> 190:         return (int)s;
> 191:     }
> 192: }

Watch for newlines

src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 83:

> 81:  * ConstantPool.
> 82:  */
> 83: public final class SplitConstantPool implements ConstantPoolBuilder {

Not sure the "Split" prefix carries any meaning? (perhaps a leftover from previous iterations?)

src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 217:

> 215:                 }
> 216:             };
> 217:             // Doing a full scan here yields fall-off-the-cliff performance results,

Understanding checkpoint: the parent is a class reader, which holds some class bytes. The class reader is set up in a way that constant pool entries are read "on-demand" - that is, if I ask the class reader "give me CP entry 42", the classreader will only build that entry (assuming 42 is a valid index) and give me back that entry. Also, the class reader will save the read constant in an internal array, to avoid re-reading the classfile bytes multiple times.

So, what this code here does is: when we create an entry map, we populate the map with the entries from the parent reader - but we only add entries that were already looked up (e.g. we do not bother reading _all_ entries, and adding all of them to the entry map).

But, when `findEntry` is called, if we see that we can't find the entry, and we know that there might be constant pool entries from the parent reader still unread, we force a full scan of the parent reader pool and try again.

Correct?

src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 271:

> 269: 
> 270:     private <E extends PoolEntry> E internalAdd(E cpi, int hash) {
> 271:         int newIndex = size-parentSize;

I'm not sure I get this. The new entry is constructed with an index set to the pool size. That said, when we build the entry we don't yet know if the entry is already in the pool. The EntryMap data structure seems to have logic to detect duplicates (e.g. adding an already added entry is a no-op) - but this method seems to (a) add the CP entry to the `newEntries` array anyway and (b) happily return the entry with the index set to the pool size (which might, or might not, be the correct final index). What am I missing?

src/java.base/share/classes/jdk/internal/classfile/impl/TargetInfoImpl.java line 34:

> 32: 
> 33: /**
> 34:  *

Empty javadoc?

src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java line 60:

> 58:     private static final Options options = new Options(Collections.emptyList());
> 59: 
> 60:     private TemporaryConstantPool() {};

If I understand correctly, this constant pool is just "fake" in the sense that it's a builder which creates constant pool entries w/o storing them anywhere. This seems to be used in places where e.g. we need to convert a ClassDesc to a ClassEntry, probably so that the implementation of e.g. attributes can be defined in terms of constant pool entries, even when "unbounded". E.g. this is a trick which avoids having completely different representations for bound and unbound elements - correct?

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

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


From mcimadamore at openjdk.org  Thu Feb 16 12:58:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 12:58:56 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>
Message-ID: <pcDodfQdDJtkKPXj0UcDAk4qWFbMvUuYLomzuvJor1E=.9fe5504c-ee1c-41a1-822b-2b1244699bf7@github.com>

On Thu, 16 Feb 2023 12:46:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 271:
> 
>> 269: 
>> 270:     private <E extends PoolEntry> E internalAdd(E cpi, int hash) {
>> 271:         int newIndex = size-parentSize;
> 
> I'm not sure I get this. The new entry is constructed with an index set to the pool size. That said, when we build the entry we don't yet know if the entry is already in the pool. The EntryMap data structure seems to have logic to detect duplicates (e.g. adding an already added entry is a no-op) - but this method seems to (a) add the CP entry to the `newEntries` array anyway and (b) happily return the entry with the index set to the pool size (which might, or might not, be the correct final index). What am I missing?

Nevermind - this method is only called if the entry is not found (using `findEntry`) :-)

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

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


From thomas.stuefe at gmail.com  Thu Feb 16 13:38:37 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 16 Feb 2023 14:38:37 +0100
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++
In-Reply-To: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
Message-ID: <CAA-vtUxCkjHtM32eJUNZoNtLcSzi5rMRXT7xzhY+ZoEGY_n2wQ@mail.gmail.com>

I?m curious, why does the options function have to be exported? Who is
consuming it?

On Wed 15. Feb 2023 at 19:01, Justin King <jcking at openjdk.org> wrote:

> Update build-related infrastructure to support building with ASan under
> Microsoft Visual C++.
>
> -------------
>
> Commit messages:
>  - Move comment to appropriate location
>  - Use elif instead of separate if
>  - Only pass -fsanitize=address to linker for Clang/GCC
>  - Update asan_default_options.c with MSVC-specific extensions
>  - Support using ASan with MSVC
>
> Changes: https://git.openjdk.org/jdk/pull/12580/files
>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12580&range=00
>   Issue: https://bugs.openjdk.org/browse/JDK-8302599
>   Stats: 25 lines in 2 files changed: 18 ins; 0 del; 7 mod
>   Patch: https://git.openjdk.org/jdk/pull/12580.diff
>   Fetch: git fetch https://git.openjdk.org/jdk pull/12580/head:pull/12580
>
> PR: https://git.openjdk.org/jdk/pull/12580
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230216/e6eeacc9/attachment.htm>

From jwaters at openjdk.org  Thu Feb 16 14:24:48 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Feb 2023 14:24:48 GMT
Subject: Withdrawn: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
Message-ID: <4SofE45cJ1a4mlTSR_XKz_r0BBtmH0bKMOjH-DeJc-c=.89ce881e-fb84-43ca-88a3-347738b8225f@github.com>

On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Full details in linked entry, man did this give me a scare on my local branch
> 
> All C++ compilers for the build operating system are under the name c++ (when selected compiler is gcc), but when searching for BUILD_CXX the compiler given priority is an uppercase CC, and then g++, which is not correct since this simply links to the C compiler instead

This pull request has been closed without being integrated.

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

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


From jwaters at openjdk.org  Thu Feb 16 14:24:47 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Feb 2023 14:24:47 GMT
Subject: RFR: 8302460: System C++ Compiler for cross compiling gcc is
 dangerously wrong
In-Reply-To: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
References: <hKCnXgV9AtoinKbM2ytzKoCXFhRM1n6uGdy1M-GuSEU=.bf679268-d6ee-4732-a38d-c0bb4928150e@github.com>
Message-ID: <_g9elRyoWUmVSMKfJPcMSfNqVcGDE2Ol4do2n-a4Xag=.7489412e-92a3-49f4-827e-a56088a4cd1d@github.com>

On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Full details in linked entry, man did this give me a scare on my local branch
> 
> All C++ compilers for the build operating system are under the name c++ (when selected compiler is gcc), but when searching for BUILD_CXX the compiler given priority is an uppercase CC, and then g++, which is not correct since this simply links to the C compiler instead

Perhaps yes, I'll close this and the related entry since we can't agree on what to do with the build compiler, and that it sounds more complex than I initially thought

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

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


From duke at openjdk.org  Thu Feb 16 14:45:13 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 14:45:13 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
Message-ID: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>

Improves performance and correctness, as discussed on the net-dev mailing list.

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

Commit messages:
 - Fix whitespace issues
 - Remove executable bit from NetworkInterface.c
 - Rewrite Windows native code for NetworkInterface to improve performance and correctness

Changes: https://git.openjdk.org/jdk/pull/12593/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302659
  Stats: 2347 lines in 5 files changed: 302 ins; 1803 del; 242 mod
  Patch: https://git.openjdk.org/jdk/pull/12593.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12593/head:pull/12593

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


From dfuchs at openjdk.org  Thu Feb 16 14:45:13 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 Feb 2023 14:45:13 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
In-Reply-To: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
Message-ID: <22xuSAye4wy4y4o4P8M87xa4-3zuFUclmsdB-RiJ-zI=.10ef14d4-a536-47c3-91f6-d43456a63b65@github.com>

On Thu, 16 Feb 2023 14:32:15 GMT, Rich DiCroce <duke at openjdk.org> wrote:

> Improves performance and correctness, as discussed on the net-dev mailing list.

FWIW - there is a perl script located in `make/scripts/normalizer.pl` that can be run on modified sources to fix up whitespace  and CRLF issues when jcheck complains.

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

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


From alanb at openjdk.org  Thu Feb 16 14:52:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Feb 2023 14:52:28 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
In-Reply-To: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
Message-ID: <zoIXuP8P4ER0h6O6wPDp9V52z28Ofaa24kMD8JiQ_Xs=.adb08763-6c9b-4aa3-85f4-0a964a0ac3e6@github.com>

On Thu, 16 Feb 2023 14:32:15 GMT, Rich DiCroce <duke at openjdk.org> wrote:

> Improves performance and correctness, as discussed on the net-dev mailing list.

Would it be possible to re-format the changes to src/java.base/windows/native/libnet/NetworkInterface.c to avoid the overly long lines - some of the new lines are 150-200 characters long so it will make impossible to look at side-by-side diffs in the future.

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

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


From mcimadamore at openjdk.org  Thu Feb 16 15:03:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 16 Feb 2023 15:03:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
Message-ID: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>

On Thu, 16 Feb 2023 10:41:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added 4-byte Unicode text to Utf8EntryTest

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 75:

> 73:     static ConstantPoolBuilder of(ClassModel classModel) {
> 74:         ClassReader reader = (ClassReader) classModel.constantPool();
> 75:         return reader.optionValue(Classfile.Option.Key.CP_SHARING)

Question: the fact that, when transforming, the new constant pool is the same as the old one, plus some "appended" entries at the end, is a pretty crucial property to ensure that existing code that is not transformed (e.g. unknown attributes) remains legal after transformation. But it seems that, if the `CP_SHARING` option is not passed, we build a brand new constant pool, in which case there's no guarantee that old indices will still point to the same position. Doesn't that lead to issue with unknown attributes?

I guess my question is: shouldn't the semantics properties/guarantees of a classfile transform be specified regardless of the options being passed in? E.g. it's ok if using different options ends up with different performance model, but I'm a bit worried if options can affect correctness of the transform?

src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 38:

> 36:     private final List<Attribute<?>> attributes = new ArrayList<>();
> 37: 
> 38:     public AttributeHolder() {

default constructor

src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 54:

> 52:  */
> 53: public class BytecodeHelpers {
> 54: //    public static Map<ConstantDesc, Opcode> constantsToOpcodes = new HashMap<>(16);

Should this be removed?

src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 56:

> 54: //    public static Map<ConstantDesc, Opcode> constantsToOpcodes = new HashMap<>(16);
> 55: 
> 56:     public BytecodeHelpers() {

Should this also be removed (same as default constructor) ?

src/java.base/share/classes/jdk/internal/classfile/impl/ChainedFieldBuilder.java line 48:

> 46:         this.consumer = consumer;
> 47:         FieldBuilder b = downstream;
> 48:         while (b instanceof ChainedFieldBuilder cb)

I'm probably missing something - but if `b` is another chained builder, instead of using a loop, can't we just skip to its  `terminal` field? Also, the `downstream` field seems unused. (same considerations apply for `ChainedMethodBuilder` and `ChainedClassBuilder`).

I note that `NonTerminalCodeBuilder` seems to be already doing what I suggest here (e.g. skip to `terminal`).

src/java.base/share/classes/jdk/internal/classfile/impl/ConcreteEntry.java line 58:

> 56: import jdk.internal.classfile.jdktypes.PackageDesc;
> 57: 
> 58: public abstract sealed class ConcreteEntry {

Why the name `concrete` ? Am I missing something (e.g. existence of "non-concrete" pool entries?)

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 649:

> 647:             if (parentMap == null)
> 648:                 parentMap = new IdentityHashMap<>();
> 649:             int[] table = parentMap.computeIfAbsent(parent, new Function<CodeAttribute, int[]>() {

Can use a lambda here?

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 658:

> 656:             mruParent = parent;
> 657:             mruParentTable = table;
> 658:             return mruParentTable[lab.getContextInfo()] - 1;

Am I correct that this code can misbehave e.g. if `computeIfAbsent` ends up creating a brand new `table` array - in which case, all array elements are set to `0` - meaning we end up returning `-1`. Is that what we want?

src/java.base/share/classes/jdk/internal/classfile/impl/InstructionData.java line 47:

> 45:  * InstructionData
> 46:  */
> 47: public class InstructionData {

As CodeImpl seems to be the only client of this, I wonder if we could move the static cache in there?

src/java.base/share/classes/jdk/internal/classfile/impl/LabelImpl.java line 65:

> 63: 
> 64:     public int getContextInfo() {
> 65:         return contextInfo;

This seems to be the BCI - should we change names to reflect that? (`contextInfo` seems very vague)

src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java line 51:

> 49:  * TransformImpl
> 50:  */
> 51: public class TransformImpl {

Understanding check: a transform implementation is made up of two runnable (start/end handlers) and a consumer. The consumer can be used e.g. to iterate and transform all the contents of a compound element (e.g. all the instruction in a code attribute).

User-defined transforms can be "resolved" that is, we can "bind" them to a specific builder, which effectively turns them into consumers (and into a concrete transform implementation that can be used).

When two transforms T1 and T2 are composed (so that T1 runs before T2), we need to implement the `resolve` method of the resulting transform so that:
* We resolve T2 against the provided builder - this gives us a "downstream" consumer;
* We create a new "chained" builder which wraps the provided builder, and whose `with` method calls the downstream consumer;
* We then resolve T1 against the chained builder, and return the resulting consumer

This means that when we call `accept` on the resulting consumer, we will transform (using T1) and call `with` (passing the transformed element)  on the chained builder, which will end up calling `accept` on the downstream consumer, which will apply T2 and finally add the resulting element to the provided builder.

Correct? (Phew)

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

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


From duke at openjdk.org  Thu Feb 16 15:17:27 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 15:17:27 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
In-Reply-To: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
Message-ID: <Vn-LA6-FUuVXDCOQ32Cod_JdZ86EntuoVZjm8J-42-M=.9b8e56eb-ea5a-4e48-8b0c-b1bcfe7e157a@github.com>

On Thu, 16 Feb 2023 14:32:15 GMT, Rich DiCroce <duke at openjdk.org> wrote:

> Improves performance and correctness, as discussed on the net-dev mailing list.

Sure. What do you want the max line length to be? 80 chars? 100?

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

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


From jcking at google.com  Thu Feb 16 15:44:24 2023
From: jcking at google.com (Justin King)
Date: Thu, 16 Feb 2023 07:44:24 -0800
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++
In-Reply-To: <CAA-vtUxCkjHtM32eJUNZoNtLcSzi5rMRXT7xzhY+ZoEGY_n2wQ@mail.gmail.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
 <CAA-vtUxCkjHtM32eJUNZoNtLcSzi5rMRXT7xzhY+ZoEGY_n2wQ@mail.gmail.com>
Message-ID: <CAEdz=WV_nLqH1taMbva4_i_yGdDaXs6Eym2w8Pm3Z-Au_Dxsag@mail.gmail.com>

It is consumed by the ASan runtime itself, which is loaded first well
before main(int, char**) is invoked. In order for ASan to find it, the
symbol to it has to be exported. See references to __asan_default_options
in
https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/asan/asan_flags.cpp.
GCC uses the same runtime library as does MSVC.

On Thu, Feb 16, 2023 at 5:38 AM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> I?m curious, why does the options function have to be exported? Who is
> consuming it?
>
> On Wed 15. Feb 2023 at 19:01, Justin King <jcking at openjdk.org> wrote:
>
>> Update build-related infrastructure to support building with ASan under
>> Microsoft Visual C++.
>>
>> -------------
>>
>> Commit messages:
>>  - Move comment to appropriate location
>>  - Use elif instead of separate if
>>  - Only pass -fsanitize=address to linker for Clang/GCC
>>  - Update asan_default_options.c with MSVC-specific extensions
>>  - Support using ASan with MSVC
>>
>> Changes: https://git.openjdk.org/jdk/pull/12580/files
>>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12580&range=00
>>   Issue: https://bugs.openjdk.org/browse/JDK-8302599
>>   Stats: 25 lines in 2 files changed: 18 ins; 0 del; 7 mod
>>   Patch: https://git.openjdk.org/jdk/pull/12580.diff
>>   Fetch: git fetch https://git.openjdk.org/jdk pull/12580/head:pull/12580
>>
>> PR: https://git.openjdk.org/jdk/pull/12580
>>
>

-- 

[image: Google Logo]
Justin King
Software Engineer
jcking at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230216/12b69aa8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3999 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230216/12b69aa8/smime.p7s>

From dfuchs at openjdk.org  Thu Feb 16 15:50:26 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 Feb 2023 15:50:26 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
In-Reply-To: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
Message-ID: <DBhDlMCJvFTzLhP8mQrwTrIvXMZsGoJhCfESp0b956E=.cc9f5ac9-551b-4b76-b01a-4b8cadbaae2e@github.com>

On Thu, 16 Feb 2023 14:32:15 GMT, Rich DiCroce <duke at openjdk.org> wrote:

> Improves performance and correctness, as discussed on the net-dev mailing list.

Something between 80 and 100 is usually a good limit. We typically avoid to go above that. So no hard limit at 80 but avoid having lines which are too long. If it displays correctly without wrapping using side diff in webrev / github side diff file view it's a good sign.

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

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


From stuefe at openjdk.org  Thu Feb 16 16:18:27 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 16 Feb 2023 16:18:27 GMT
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++
In-Reply-To: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
Message-ID: <u4yn3EgtD7WrwfIm8JhQrW_p22R9pnSL0ql6_fCQWg0=.cbaadc6f-b5d5-49e5-a1a5-490622eac035@github.com>

On Wed, 15 Feb 2023 17:53:49 GMT, Justin King <jcking at openjdk.org> wrote:

> Update build-related infrastructure to support building with ASan under Microsoft Visual C++.

LGTM. Build error on Mac x64 seems unrelated.

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

Marked as reviewed by stuefe (Reviewer).

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


From ihse at openjdk.org  Thu Feb 16 16:24:29 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 16 Feb 2023 16:24:29 GMT
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++
In-Reply-To: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
Message-ID: <wrBmYBWiNdk2m0JPKY1np554O78o9tnR7bcHe0opm40=.dea2ea46-b3a2-4f09-b6c1-127dd7e11978@github.com>

On Wed, 15 Feb 2023 17:53:49 GMT, Justin King <jcking at openjdk.org> wrote:

> Update build-related infrastructure to support building with ASan under Microsoft Visual C++.

make/autoconf/jdk-options.m4 line 438:

> 436:         elif test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
> 437:           # MSVC produces a warning if you pass -fsanitize=address to the linker.
> 438:           ASAN_CFLAGS="$ASAN_CFLAGS -Oy-"

What is the purpose of `/Oy-`? Can you explain it in a short comment?

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

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


From ihse at openjdk.org  Thu Feb 16 16:30:31 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 16 Feb 2023 16:30:31 GMT
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++
In-Reply-To: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
Message-ID: <eadkDZehA1lOHzmAMJWXp4ng_sMGR68Fjj9UzO1_x6g=.6681519d-b1ec-4503-ba57-d7dfa1cb0668@github.com>

On Wed, 15 Feb 2023 17:53:49 GMT, Justin King <jcking at openjdk.org> wrote:

> Update build-related infrastructure to support building with ASan under Microsoft Visual C++.

It basically looks good but need some more polishing.

make/autoconf/jdk-options.m4 line 427:

> 425:       ],
> 426:       IF_ENABLED: [
> 427:         ASAN_CFLAGS="-fsanitize=address"

It seems like more of a coincidence than a obvious fact to base the design on that `-fsanitize=address` happens to work on both ms cl.exe and gcc/clang.

Maybe this is the herald of a new age of compiler switches getting cross-compiler standard names (let's hope!), but I think it still makes more sense to not share CFLAGS between microsoft and clang/gcc.

Or, more concretely: There is no need to define `ASAN_CFLAGS` and `ASAN_LDFLAGS` outside the two toolchain specific clauses.

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

Marked as reviewed by ihse (Reviewer).

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


From ihse at openjdk.org  Thu Feb 16 16:34:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 16 Feb 2023 16:34:25 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
In-Reply-To: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
Message-ID: <9ZRbs8Xp8jY5gUmj5JkS-3k6sGI1Ey0K4y455NUpuf0=.a357c8e7-8b91-4f20-93ee-efd9e7d30a58@github.com>

On Thu, 16 Feb 2023 14:32:15 GMT, Rich DiCroce <duke at openjdk.org> wrote:

> Improves performance and correctness, as discussed on the net-dev mailing list.

Build changes look fine.

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

Marked as reviewed by ihse (Reviewer).

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


From duke at openjdk.org  Thu Feb 16 16:49:09 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 16:49:09 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
Message-ID: <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>

> Improves performance and correctness, as discussed on the net-dev mailing list.

Rich DiCroce has updated the pull request incrementally with one additional commit since the last revision:

  Limit line length to 80-ish characters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12593/files
  - new: https://git.openjdk.org/jdk/pull/12593/files/311cdc22..b23d139e

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

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

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


From duke at openjdk.org  Thu Feb 16 16:49:12 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 16:49:12 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
In-Reply-To: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
Message-ID: <GinNjS11sf6qva4EIwIQ1Biwp2_bNVTiA1Qndc6Tc78=.576466be-6a2e-4d4c-ba3a-ebfac02d6580@github.com>

On Thu, 16 Feb 2023 14:32:15 GMT, Rich DiCroce <duke at openjdk.org> wrote:

> Improves performance and correctness, as discussed on the net-dev mailing list.

Maximum line length reduced to 80-ish characters.

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

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


From djelinski at openjdk.org  Thu Feb 16 17:15:36 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 16 Feb 2023 17:15:36 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
Message-ID: <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>

On Thu, 16 Feb 2023 16:49:09 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit line length to 80-ish characters

Overall the changes look good. A few comments below.

src/java.base/windows/native/libnet/NetworkInterface.c line 2:

> 1: /*
> 2:  * Copyright (c) 2003, 2022, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2000, 2023, Oracle and/or its affiliates. All rights reserved.

src/java.base/windows/native/libnet/NetworkInterface.c line 62:

> 60: typedef struct _netaddr {
> 61:     SOCKADDR_INET Address;
> 62:     SCOPE_ID ScopeId;

Not used

src/java.base/windows/native/libnet/NetworkInterface.c line 67:

> 65: } netaddr;
> 66: 
> 67: BOOL getAddressTables(MIB_UNICASTIPADDRESS_TABLE **uniAddrs, MIB_ANYCASTIPADDRESS_TABLE **anyAddrs) {

Please mark all functions that are local to this file as `static`, this will help the compiler

src/java.base/windows/native/libnet/NetworkInterface.c line 69:

> 67: BOOL getAddressTables(MIB_UNICASTIPADDRESS_TABLE **uniAddrs, MIB_ANYCASTIPADDRESS_TABLE **anyAddrs) {
> 68:     ADDRESS_FAMILY addrFamily = ipv6_available() ? AF_UNSPEC : AF_INET;
> 69:     if (GetUnicastIpAddressTable(addrFamily, uniAddrs) != NO_ERROR) {

Please add error handling to all WinAPI calls; something like:

NET_ThrowByNameWithLastError(env, JNU_JAVANETPKG "SocketException", "GetUnicastIpAddressTable");

You may also need to use `SetLastError(ret)` before calling NET_Throw...; the WinAPI functions are not documented to do it, and we do not have a function that would take the error code as a parameter.

src/java.base/windows/native/libnet/NetworkInterface.c line 72:

> 70:         return FALSE;
> 71:     }
> 72:     if (GetAnycastIpAddressTable(addrFamily, anyAddrs) != NO_ERROR) {

Were the anycast addresses covered by the existing code, or is this a functional change?

src/java.base/windows/native/libnet/NetworkInterface.c line 393:

> 391:  * Signature: ()[Ljava/net/NetworkInterface;
> 392:  */
> 393: JNIEXPORT jobjectArray JNICALL Java_java_net_NetworkInterface_getAll(JNIEnv *env, jclass cls) {

This may have also fixed [JDK-6798979](https://bugs.openjdk.org/browse/JDK-6798979) and [JDK-8165665](https://bugs.openjdk.org/browse/JDK-8165665) (which is a good thing!)

src/java.base/windows/native/libnet/NetworkInterface.c line 523:

> 521:  * Signature: (Ljava/lang/String;I)Z
> 522:  */
> 523: JNIEXPORT jboolean JNICALL Java_java_net_NetworkInterface_supportsMulticast0(JNIEnv *env, jclass cls, jstring name, jint index) {

I'm not a big fan of using WBEM here. Also, I'm still trying to figure out when (if ever) this method is supposed to return false

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

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


From duke at openjdk.org  Thu Feb 16 17:59:30 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 17:59:30 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
Message-ID: <YrqcagiZH-PmknZqRyWNS0odIVn4mynZYVuLX6-WnHM=.908a9ca0-ec91-4160-8cb9-59af153f0ac9@github.com>

On Thu, 16 Feb 2023 16:08:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Rich DiCroce has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Limit line length to 80-ish characters
>
> src/java.base/windows/native/libnet/NetworkInterface.c line 72:
> 
>> 70:         return FALSE;
>> 71:     }
>> 72:     if (GetAnycastIpAddressTable(addrFamily, anyAddrs) != NO_ERROR) {
> 
> Were the anycast addresses covered by the existing code, or is this a functional change?

For the IPv6 code, this should be the same as before. See getAddrsFromAdapter in the original code, which enumerates the unicast addresses first and then does the anycast addresses.

For IPv4, I'm not sure. The MS docs for GetIpAddrTable don't say, and I don't have any systems where I could determine it experimentally.

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

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


From msheppar at openjdk.org  Thu Feb 16 18:04:28 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 16 Feb 2023 18:04:28 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
Message-ID: <kdM7TlJzQJpNOkj4qRqaPHeB50FD5xSHm7_5wFGeEyM=.511d4162-b349-41b6-80fe-47a8e39d5485@github.com>

On Thu, 16 Feb 2023 16:49:09 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit line length to 80-ish characters

what versions of Windows has this been tested on ? Just wondering if the deletion of the old dual stack winXP based code could have on the older windows OS platforms?
afaik current set of supported windows OS platforms, from the ATR list, are : 
            windows server 2019,
            windows server 2022,
            windows server  2016,
            windows 10,
            windows 11,
            windows 8,
            windows server2012,
            windows server 2012R2

some of these may be retired for LTS JDK21, but for the moment they are in the mix.
We'll need to schedule test runs for all these.

Also we will have to arrange some IPv6 only test runs for this prior to any integration -- that takes a bit of time to arrange the resources to be setup and to schedule the runs.

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

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


From duke at openjdk.org  Thu Feb 16 18:07:30 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 18:07:30 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
Message-ID: <njL-lKEZ7z886PvCv4sULPOpdI0iwe-yAlsaEmTNvgY=.5ffd751e-8b8e-4dbc-9cc4-49135cfdd14c@github.com>

On Thu, 16 Feb 2023 17:08:25 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Rich DiCroce has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Limit line length to 80-ish characters
>
> src/java.base/windows/native/libnet/NetworkInterface.c line 523:
> 
>> 521:  * Signature: (Ljava/lang/String;I)Z
>> 522:  */
>> 523: JNIEXPORT jboolean JNICALL Java_java_net_NetworkInterface_supportsMulticast0(JNIEnv *env, jclass cls, jstring name, jint index) {
> 
> I'm not a big fan of using WBEM here. Also, I'm still trying to figure out when (if ever) this method is supposed to return false

You and me both. As I wrote in the giant comment, I did a lot of experimenting. In the end, what I determined was that if the IGMPLevel (IPv4) or MldLevel (IPv6) is set to 0 (None), then attempting to join a multicast group throws an exception. So that seemed like a reasonable thing that supportsMulticast() could measure. Nothing else I tried, including the existing GetAdaptersAddresses approach, indicated that multicast was disabled in those situations.

Having said that, I'd be okay with ditching all of this code and just returning true unconditionally. It's unlikely that multicast would be disabled, and a single boolean isn't enough to express the actual setting anyway, since Windows apparently lets you disable receiving multicasts while still allowing you to send them.

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

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


From duke at openjdk.org  Thu Feb 16 18:11:29 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 18:11:29 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <kdM7TlJzQJpNOkj4qRqaPHeB50FD5xSHm7_5wFGeEyM=.511d4162-b349-41b6-80fe-47a8e39d5485@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <kdM7TlJzQJpNOkj4qRqaPHeB50FD5xSHm7_5wFGeEyM=.511d4162-b349-41b6-80fe-47a8e39d5485@github.com>
Message-ID: <IXQXPN7i87jTyYSnNNWv5nADQLj_9UXv59nk6BA_Zn8=.69581f90-91e8-42e7-a6fb-ddf4a79bc3db@github.com>

On Thu, 16 Feb 2023 18:01:43 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Rich DiCroce has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Limit line length to 80-ish characters
>
> what versions of Windows has this been tested on ? Just wondering if the deletion of the old dual stack winXP based code could have on the older windows OS platforms?
> afaik current set of supported windows OS platforms, from the ATR list, are : 
>             windows server 2019,
>             windows server 2022,
>             windows server  2016,
>             windows 10,
>             windows 11,
>             windows 8,
>             windows server2012,
>             windows server 2012R2
> 
> some of these may be retired for LTS JDK21, but for the moment they are in the mix.
> We'll need to schedule test runs for all these.
> 
> Also we will have to arrange some IPv6 only test runs for this prior to any integration -- that takes a bit of time to arrange the resources to be setup and to schedule the runs.

@msheppar I tested this on Windows 10 and 11. I don't have access to any older systems. But I tried to be careful about which APIs I used. I'm pretty sure I checked the MS docs for all of them, and they all exist since Vista/Server 2008. So this should work on all the versions you listed.

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

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


From djelinski at openjdk.org  Thu Feb 16 18:56:30 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 16 Feb 2023 18:56:30 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <njL-lKEZ7z886PvCv4sULPOpdI0iwe-yAlsaEmTNvgY=.5ffd751e-8b8e-4dbc-9cc4-49135cfdd14c@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
 <njL-lKEZ7z886PvCv4sULPOpdI0iwe-yAlsaEmTNvgY=.5ffd751e-8b8e-4dbc-9cc4-49135cfdd14c@github.com>
Message-ID: <1en36lUgplk03paOtfrxk-Aoiop5Toe2Sd7oVcx74K4=.ef33f250-b03a-44d8-adcc-1e3dff6b55dc@github.com>

On Thu, 16 Feb 2023 18:05:05 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> src/java.base/windows/native/libnet/NetworkInterface.c line 523:
>> 
>>> 521:  * Signature: (Ljava/lang/String;I)Z
>>> 522:  */
>>> 523: JNIEXPORT jboolean JNICALL Java_java_net_NetworkInterface_supportsMulticast0(JNIEnv *env, jclass cls, jstring name, jint index) {
>> 
>> I'm not a big fan of using WBEM here. Also, I'm still trying to figure out when (if ever) this method is supposed to return false
>
> You and me both. As I wrote in the giant comment, I did a lot of experimenting. In the end, what I determined was that if the IGMPLevel (IPv4) or MldLevel (IPv6) is set to 0 (None), then attempting to join a multicast group throws an exception. So that seemed like a reasonable thing that supportsMulticast() could measure. Nothing else I tried, including the existing GetAdaptersAddresses approach, indicated that multicast was disabled in those situations.
> 
> Having said that, I'd be okay with ditching all of this code and just returning true unconditionally. It's unlikely that multicast would be disabled, and a single boolean isn't enough to express the actual setting anyway, since Windows apparently lets you disable receiving multicasts while still allowing you to send them.

Ha! Apparently I have a machine where the implementation of `supportsMulticast` implementation makes a difference. On my machine the test `jdk/java/net/SocketOption/OptionsTest.java` is failing with:

java.net.SocketException: Invalid argument: no further information
	at java.base/sun.nio.ch.Net.setInterface6(Native Method)
	at java.base/sun.nio.ch.DatagramChannelImpl.setOption(DatagramChannelImpl.java:377)
	at java.base/sun.nio.ch.DatagramSocketAdaptor.setOption(DatagramSocketAdaptor.java:431)
	at java.base/java.net.DatagramSocket.setOption(DatagramSocket.java:1207)
	at OptionsTest.test(OptionsTest.java:155)
	at OptionsTest.doMulticastSocketTests(OptionsTest.java:235)
	at OptionsTest.main(OptionsTest.java:337)
...

It works with the current master. Will try to figure it out.

BTW. did you try running jdk_net tests?

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

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


From duke at openjdk.org  Thu Feb 16 19:01:27 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 19:01:27 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <1en36lUgplk03paOtfrxk-Aoiop5Toe2Sd7oVcx74K4=.ef33f250-b03a-44d8-adcc-1e3dff6b55dc@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
 <njL-lKEZ7z886PvCv4sULPOpdI0iwe-yAlsaEmTNvgY=.5ffd751e-8b8e-4dbc-9cc4-49135cfdd14c@github.com>
 <1en36lUgplk03paOtfrxk-Aoiop5Toe2Sd7oVcx74K4=.ef33f250-b03a-44d8-adcc-1e3dff6b55dc@github.com>
Message-ID: <ZTK_RPj42NlKZXGbE7jpBLr5CLG-u3byte3KM1fU1-A=.e2d89b9b-f524-4aff-b330-d46c95d6894c@github.com>

On Thu, 16 Feb 2023 18:54:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> You and me both. As I wrote in the giant comment, I did a lot of experimenting. In the end, what I determined was that if the IGMPLevel (IPv4) or MldLevel (IPv6) is set to 0 (None), then attempting to join a multicast group throws an exception. So that seemed like a reasonable thing that supportsMulticast() could measure. Nothing else I tried, including the existing GetAdaptersAddresses approach, indicated that multicast was disabled in those situations.
>> 
>> Having said that, I'd be okay with ditching all of this code and just returning true unconditionally. It's unlikely that multicast would be disabled, and a single boolean isn't enough to express the actual setting anyway, since Windows apparently lets you disable receiving multicasts while still allowing you to send them.
>
> Ha! Apparently I have a machine where the implementation of `supportsMulticast` implementation makes a difference. On my machine the test `jdk/java/net/SocketOption/OptionsTest.java` is failing with:
> 
> java.net.SocketException: Invalid argument: no further information
> 	at java.base/sun.nio.ch.Net.setInterface6(Native Method)
> 	at java.base/sun.nio.ch.DatagramChannelImpl.setOption(DatagramChannelImpl.java:377)
> 	at java.base/sun.nio.ch.DatagramSocketAdaptor.setOption(DatagramSocketAdaptor.java:431)
> 	at java.base/java.net.DatagramSocket.setOption(DatagramSocket.java:1207)
> 	at OptionsTest.test(OptionsTest.java:155)
> 	at OptionsTest.doMulticastSocketTests(OptionsTest.java:235)
> 	at OptionsTest.main(OptionsTest.java:337)
> ...
> 
> It works with the current master. Will try to figure it out.
> 
> BTW. did you try running jdk_net tests?

I ran the tests for NetworkInterface specifically, though that reminds me that I need to open a bug report about fixpath mangling things incorrectly. I'll give the full jdk_net suite a run and see what happens.

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

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


From ihse at openjdk.org  Thu Feb 16 19:18:03 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 16 Feb 2023 19:18:03 GMT
Subject: RFR: 8301753: AppendFile/WriteFile has differences between make 3.81
 and 4+
Message-ID: <FcTcepFH2BpNDRUy2KP3_sDL4sTg8yEr03ZILYKUCFo=.46f28971-adb8-4814-90d9-5a779e551ab1@github.com>

This is a retake on https://github.com/openjdk/jdk/pull/12461. Changes compared to the original patch:

Both WriteFile and AppendFile are fixed. 

It turned out we actually did a `$(strip)` on the input for the `$(file)` variant, so for consistency we should do that for the make 3.81 as well. Almost as a side-effect, this will also handle the problem of risking to add multiple newlines, since any trailing newlines will be removed by the strip, and then we can always append a newline.

Unit tests are added. I have verified functionality on make 3.81, 4.0 and 4.4.

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

Commit messages:
 - 8301753: AppendFile/WriteFile has differences between make 3.81 and 4+

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

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


From erikj at openjdk.org  Thu Feb 16 19:18:03 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 19:18:03 GMT
Subject: RFR: 8301753: AppendFile/WriteFile has differences between make
 3.81 and 4+
In-Reply-To: <FcTcepFH2BpNDRUy2KP3_sDL4sTg8yEr03ZILYKUCFo=.46f28971-adb8-4814-90d9-5a779e551ab1@github.com>
References: <FcTcepFH2BpNDRUy2KP3_sDL4sTg8yEr03ZILYKUCFo=.46f28971-adb8-4814-90d9-5a779e551ab1@github.com>
Message-ID: <16nybV5N1lWXHsu3RU9_H85cCGo-t5sRsrvUl5sUNZk=.bd26c372-34ff-4732-b6f5-58fb8403856f@github.com>

On Thu, 16 Feb 2023 19:08:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a retake on https://github.com/openjdk/jdk/pull/12461. Changes compared to the original patch:
> 
> Both WriteFile and AppendFile are fixed. 
> 
> It turned out we actually did a `$(strip)` on the input for the `$(file)` variant, so for consistency we should do that for the make 3.81 as well. Almost as a side-effect, this will also handle the problem of risking to add multiple newlines, since any trailing newlines will be removed by the strip, and then we can always append a newline.
> 
> Unit tests are added. I have verified functionality on make 3.81, 4.0 and 4.4.

Marked as reviewed by erikj (Reviewer).

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

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


From ihse at openjdk.org  Thu Feb 16 19:35:35 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 16 Feb 2023 19:35:35 GMT
Subject: Integrated: 8301753: AppendFile/WriteFile has differences between make
 3.81 and 4+
In-Reply-To: <FcTcepFH2BpNDRUy2KP3_sDL4sTg8yEr03ZILYKUCFo=.46f28971-adb8-4814-90d9-5a779e551ab1@github.com>
References: <FcTcepFH2BpNDRUy2KP3_sDL4sTg8yEr03ZILYKUCFo=.46f28971-adb8-4814-90d9-5a779e551ab1@github.com>
Message-ID: <ZcNxp-gBKpqCu7VpXvGKpKt4WIi0cWj17o-26lCvj0Q=.367d549a-b37b-4f2c-b1d1-57078250c4cf@github.com>

On Thu, 16 Feb 2023 19:08:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a retake on https://github.com/openjdk/jdk/pull/12461. Changes compared to the original patch:
> 
> Both WriteFile and AppendFile are fixed. 
> 
> It turned out we actually did a `$(strip)` on the input for the `$(file)` variant, so for consistency we should do that for the make 3.81 as well. Almost as a side-effect, this will also handle the problem of risking to add multiple newlines, since any trailing newlines will be removed by the strip, and then we can always append a newline.
> 
> Unit tests are added. I have verified functionality on make 3.81, 4.0 and 4.4.

This pull request has now been integrated.

Changeset: a39cf2e3
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a39cf2e3b242298fbf5fafdb8aa9b5d4562061ef
Stats:     58 lines in 2 files changed: 56 ins; 0 del; 2 mod

8301753: AppendFile/WriteFile has differences between make 3.81 and 4+

Reviewed-by: erikj

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

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


From djelinski at openjdk.org  Thu Feb 16 19:41:27 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 16 Feb 2023 19:41:27 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <ZTK_RPj42NlKZXGbE7jpBLr5CLG-u3byte3KM1fU1-A=.e2d89b9b-f524-4aff-b330-d46c95d6894c@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
 <njL-lKEZ7z886PvCv4sULPOpdI0iwe-yAlsaEmTNvgY=.5ffd751e-8b8e-4dbc-9cc4-49135cfdd14c@github.com>
 <1en36lUgplk03paOtfrxk-Aoiop5Toe2Sd7oVcx74K4=.ef33f250-b03a-44d8-adcc-1e3dff6b55dc@github.com>
 <ZTK_RPj42NlKZXGbE7jpBLr5CLG-u3byte3KM1fU1-A=.e2d89b9b-f524-4aff-b330-d46c95d6894c@github.com>
Message-ID: <KXOgOmZJcNXej2bqOW8i8jffiOXgtMi42tuZ4U1Jgkw=.3f05fe94-8a9c-463d-820c-7e46ea92c56c@github.com>

On Thu, 16 Feb 2023 18:59:06 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Ha! Apparently I have a machine where the implementation of `supportsMulticast` implementation makes a difference. On my machine the test `jdk/java/net/SocketOption/OptionsTest.java` is failing with:
>> 
>> java.net.SocketException: Invalid argument: no further information
>> 	at java.base/sun.nio.ch.Net.setInterface6(Native Method)
>> 	at java.base/sun.nio.ch.DatagramChannelImpl.setOption(DatagramChannelImpl.java:377)
>> 	at java.base/sun.nio.ch.DatagramSocketAdaptor.setOption(DatagramSocketAdaptor.java:431)
>> 	at java.base/java.net.DatagramSocket.setOption(DatagramSocket.java:1207)
>> 	at OptionsTest.test(OptionsTest.java:155)
>> 	at OptionsTest.doMulticastSocketTests(OptionsTest.java:235)
>> 	at OptionsTest.main(OptionsTest.java:337)
>> ...
>> 
>> It works with the current master. Will try to figure it out.
>> 
>> BTW. did you try running jdk_net tests?
>
> I ran the tests for NetworkInterface specifically, though that reminds me that I need to open a bug report about fixpath mangling things incorrectly. I'll give the full jdk_net suite a run and see what happens.

ok so here goes: your patch changes the order in which the interfaces are returned; the original code returned them in order of increasing indexes, the new code appears to sort interfaces by LUID.
The failing test uses the first interface for which supportsMulticast returns true. I get `supportsMulticast` = `true` on all interfaces even with the old code.

The interface that happened to be on the first position of my list was:

67 name:ethernet_0 (Hyper-V Virtual Switch Extension Adapter-Hyper-V Virtual Switch Extension Filter-0000)
 ifup: true isP2P: false isLoopback: false macAddr: null MTU: 1500 supportsMulticast: true

it has no associated IP addresses, and is not usable with IP_MULTICAST_IF.
(Also it's a filter interface, which means that the old code returned ifUp = false).

Well that would explain how `supportsMulticast` is meant to be used; now we just need to figure out which interfaces can be used for multicasting.

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

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


From duke at openjdk.org  Thu Feb 16 20:25:27 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 16 Feb 2023 20:25:27 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <KXOgOmZJcNXej2bqOW8i8jffiOXgtMi42tuZ4U1Jgkw=.3f05fe94-8a9c-463d-820c-7e46ea92c56c@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
 <njL-lKEZ7z886PvCv4sULPOpdI0iwe-yAlsaEmTNvgY=.5ffd751e-8b8e-4dbc-9cc4-49135cfdd14c@github.com>
 <1en36lUgplk03paOtfrxk-Aoiop5Toe2Sd7oVcx74K4=.ef33f250-b03a-44d8-adcc-1e3dff6b55dc@github.com>
 <ZTK_RPj42NlKZXGbE7jpBLr5CLG-u3byte3KM1fU1-A=.e2d89b9b-f524-4aff-b330-d46c95d6894c@github.com>
 <KXOgOmZJcNXej2bqOW8i8jffiOXgtMi42tuZ4U1Jgkw=.3f05fe94-8a9c-463d-820c-7e46ea92c56c@github.com>
Message-ID: <uLpe7n8lEcuqTgXi1oh3csHwAdKuV5WvwPYsBB252O4=.97ef5c2f-6ddc-468b-969f-e7bdf8168a0b@github.com>

On Thu, 16 Feb 2023 19:38:58 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I ran the tests for NetworkInterface specifically, though that reminds me that I need to open a bug report about fixpath mangling things incorrectly. I'll give the full jdk_net suite a run and see what happens.
>
> ok so here goes: your patch changes the order in which the interfaces are returned; the original code returned them in order of increasing indexes, the new code appears to sort interfaces by LUID.
> The failing test uses the first interface for which supportsMulticast returns true. I get `supportsMulticast` = `true` on all interfaces even with the old code.
> 
> The interface that happened to be on the first position of my list was:
> 
> 67 name:ethernet_0 (Hyper-V Virtual Switch Extension Adapter-Hyper-V Virtual Switch Extension Filter-0000)
>  ifup: true isP2P: false isLoopback: false macAddr: null MTU: 1500 supportsMulticast: true
> 
> it has no associated IP addresses, and is not usable with IP_MULTICAST_IF.
> (Also it's a filter interface, which means that the old code returned ifUp = false).
> 
> Well that would explain how `supportsMulticast` is meant to be used; now we just need to figure out which interfaces can be used for multicasting.

Note that the new code doesn't attempt to sort anything. If it happens to be sorted by LUID, that's the underlying API at work. The MS docs don't say anything about ordering, so this is probably an implementation detail and I wouldn't assume it will always be true.

I'm still running jdk_net, but I can already see that test failing on my machine. Though it has a different error:


java.io.IOException: Network interface not configured for IPv4
	at java.base/sun.nio.ch.DatagramChannelImpl.setOption(DatagramChannelImpl.java:389)
	at java.base/sun.nio.ch.DatagramSocketAdaptor.setOption(DatagramSocketAdaptor.java:431)
	at java.base/java.net.DatagramSocket.setOption(DatagramSocket.java:1207)
	at OptionsTest.test(OptionsTest.java:155)
	at OptionsTest.doMulticastSocketTests(OptionsTest.java:235)
	at OptionsTest.main(OptionsTest.java:337)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
	at java.base/java.lang.Thread.run(Thread.java:1623)


So I think when picking the interface to use for the test, we need to also check that isUp = true and that the list of IP addresses contains at least one IPv4 address.

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

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


From dfuchs at openjdk.org  Thu Feb 16 21:51:19 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 16 Feb 2023 21:51:19 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <uLpe7n8lEcuqTgXi1oh3csHwAdKuV5WvwPYsBB252O4=.97ef5c2f-6ddc-468b-969f-e7bdf8168a0b@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
 <njL-lKEZ7z886PvCv4sULPOpdI0iwe-yAlsaEmTNvgY=.5ffd751e-8b8e-4dbc-9cc4-49135cfdd14c@github.com>
 <1en36lUgplk03paOtfrxk-Aoiop5Toe2Sd7oVcx74K4=.ef33f250-b03a-44d8-adcc-1e3dff6b55dc@github.com>
 <ZTK_RPj42NlKZXGbE7jpBLr5CLG-u3byte3KM1fU1-A=.e2d89b9b-f524-4aff-b330-d46c95d6894c@github.com>
 <KXOgOmZJcNXej2bqOW8i8jffiOXgtMi42tuZ4U1Jgkw=.3f05fe94-8a9c-463d-820c-7e46ea92c56c@github.com>
 <uLpe7n8lEcuqTgXi1oh3csHwAdKuV5WvwPYsBB252O4=.97ef5c2f-6ddc-468b-969f-e7bdf8168a0b@github.com>
Message-ID: <ZtaW6W021evEqiZFkOBv956WjgTAIPlUSk6hb9RNryY=.7cd9c1a3-6566-4fbb-974e-745444807a64@github.com>

On Thu, 16 Feb 2023 20:22:17 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> ok so here goes: your patch changes the order in which the interfaces are returned; the original code returned them in order of increasing indexes, the new code appears to sort interfaces by LUID.
>> The failing test uses the first interface for which supportsMulticast returns true. I get `supportsMulticast` = `true` on all interfaces even with the old code.
>> 
>> The interface that happened to be on the first position of my list was:
>> 
>> 67 name:ethernet_0 (Hyper-V Virtual Switch Extension Adapter-Hyper-V Virtual Switch Extension Filter-0000)
>>  ifup: true isP2P: false isLoopback: false macAddr: null MTU: 1500 supportsMulticast: true
>> 
>> it has no associated IP addresses, and is not usable with IP_MULTICAST_IF.
>> (Also it's a filter interface, which means that the old code returned ifUp = false).
>> 
>> Well that would explain how `supportsMulticast` is meant to be used; now we just need to figure out which interfaces can be used for multicasting.
>
> Note that the new code doesn't attempt to sort anything. If it happens to be sorted by LUID, that's the underlying API at work. The MS docs don't say anything about ordering, so this is probably an implementation detail and I wouldn't assume it will always be true.
> 
> I'm still running jdk_net, but I can already see that test failing on my machine. Though it has a different error:
> 
> 
> java.io.IOException: Network interface not configured for IPv4
> 	at java.base/sun.nio.ch.DatagramChannelImpl.setOption(DatagramChannelImpl.java:389)
> 	at java.base/sun.nio.ch.DatagramSocketAdaptor.setOption(DatagramSocketAdaptor.java:431)
> 	at java.base/java.net.DatagramSocket.setOption(DatagramSocket.java:1207)
> 	at OptionsTest.test(OptionsTest.java:155)
> 	at OptionsTest.doMulticastSocketTests(OptionsTest.java:235)
> 	at OptionsTest.main(OptionsTest.java:337)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
> 	at java.base/java.lang.Thread.run(Thread.java:1623)
> 
> 
> So I think when picking the interface to use for the test, we need to also check that isUp = true and that the list of IP addresses contains at least one IPv4 address.

Though it's more complicated than that. Some machines may have both IPv6 and IPv4, some machine may only have IPv4, and some machine may only have IPv6. I haven't looked at the test yet, but picking up the right interface on the various platforms has always been an issue for our tests.

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

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


From duke at openjdk.org  Fri Feb 17 03:15:56 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 17 Feb 2023 03:15:56 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v5]
In-Reply-To: <ybE2QYYZQ6GU7o67rW5rpgA3JGxULHDGlTUTi-2cky8=.488673b2-40fe-49d3-9076-ac4c2b10efe0@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <ybE2QYYZQ6GU7o67rW5rpgA3JGxULHDGlTUTi-2cky8=.488673b2-40fe-49d3-9076-ac4c2b10efe0@github.com>
Message-ID: <vx8i_CIWT4jzEeeaayICiQ31DbtvF76qnu5_ttCyXg8=.c09d6ef0-d343-49b0-b0fb-92a50f8d2f0f@github.com>

On Thu, 24 Mar 2022 07:01:43 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei 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 five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8276799
>  - Fix copyright header
>  - Address review comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8276799
>  - 8276799: Implementation of JEP 422: Linux/RISC-V Port

src/hotspot/cpu/riscv/riscv.ad line 8758:

> 8756: %{
> 8757:   // Same match rule as `far_cmpU_loop'.
> 8758:   match(CountedLoopEnd cmp (CmpU op1 op2));

Which testcases can test this instruct and the following instructs?
match(CountedLoopEnd cmp (CmpP op1 op2));
match(CountedLoopEnd cmp (CmpN op1 op2));
match(CountedLoopEnd cmp (CmpF op1 op2));
match(CountedLoopEnd cmp (CmpD op1 op2));

 I suspect this instruction is useless.

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

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


From xlinzheng at openjdk.org  Fri Feb 17 03:23:26 2023
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Fri, 17 Feb 2023 03:23:26 GMT
Subject: RFR: 8302384: Handle hsdis out-of-bound logic for RISC-V
Message-ID: <I_M1Z__fBW81I-oa_1G6GyIpNaCmyf2NVFTTeSU7HJQ=.11c02ec9-41f0-4634-83b6-7526185627b8@github.com>

Several debug assertion failures have been observed on RISC-V, on physical boards only.

Failure list: (the `hs_err` log is in the JBS issue)

compiler/vectorapi/TestVectorShiftImm.java
compiler/compilercontrol/jcmd/AddPrintAssemblyTest.java
compiler/intrinsics/math/TestFpMinMaxIntrinsics.java
compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java
compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java
compiler/runtime/TestConstantsInError.java
compiler/compilercontrol/jcmd/PrintDirectivesTest.java


When the failure occurs, hsdis is disassembling the last unrecognizable data at the end of a code blob, usually the data stored in trampolines. It could be theoretically any address inside the code cache, and sometimes binutils can recognize the data as 2-byte instructions, 4-byte instructions, and 6 or 8-byte instructions even though as far as I know no instructions longer than 4-byte have landed. Therefore, binutils may firstly run out of bound after the calculation. However, the RISC-V binutils returns a `EIO` [1] (which is the `status`, always a `5`, FYI), rather than returning a `-1` (FYI, [2][3][4][5]) on other platforms when such out-of-bound happens. So when coming back to our hsdis, we (hsdis) get the `size = 5` as the return value [6] rather than `-1`: our hsdis error handling is skipped, our variable `p` is out of bound, and then we meet the crash.

To fix it, we should check the value is the special `EIO` on RISC-V. However, after fixing that issue, I found binutils would print some messages like "Address 0x%s is out of bounds." on the screen:


0x0000003f901a41b4:   auipc	t0,0x0                      ;   {trampoline_stub}
0x0000003f901a41b8:   ld	t0,12(t0) # 0x0000003f901a41c0
0x0000003f901a41bc:   jr	t0
0x0000003f901a41c0:   .2byte	0x8ec0
0x0000003f901a41c2:   srli	s0,s0,0x21
0x0000003f901a41c4:   Address 0x0000003f901a41c9 is out of bounds.      <----------- But we want the real bytes here.


So, we should overwrite the `disassemble_info.memory_error_func` in the binutils callback [7], to generate our own output:

0x0000003f901a41b4:   auipc	t0,0x0                      ;   {trampoline_stub}
0x0000003f901a41b8:   ld	t0,12(t0) # 0x0000003f901a41c0
0x0000003f901a41bc:   jr	t0
0x0000003f901a41c0:   .2byte	0x8ec0
0x0000003f901a41c2:   srli	s0,s0,0x21
0x0000003f901a41c4:   .4byte	0x0000003f


Mirroring the code of hsdis-llvm, to print merely a 4-byte data [8].


BTW, the reason why the crash only happens on the physical board, is that boards support RISC-V sv39 address mode only: a legal user-space address can be no more than 38-bit. So the code cache is always mmapped to an address like `0x3fe0000000`. Such a `0x3f` is always recognized as the mark of an 8-byte instruction [9].


Tested hotspot tier1~4 with fastdebug build, no new errors found.

Thanks,
Xiaolin


[1] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/riscv-dis.c#L940
[2] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/aarch64-dis.c#L3792
[3] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/ppc-dis.c#L872
[4] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/s390-dis.c#L305
[5] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/i386-dis.c#L9466 (the i386 one uses a `setlongjmp` to handle the exception case, so the code might look different)
[6] https://github.com/openjdk/jdk/blob/94e7cc8587356988e713d23d1653bdd5c43fb3f1/src/utils/hsdis/binutils/hsdis-binutils.c#L198
[7] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/opcodes/dis-buf.c#L51-L72
[8] https://github.com/openjdk/jdk/blob/94e7cc8587356988e713d23d1653bdd5c43fb3f1/src/utils/hsdis/llvm/hsdis-llvm.cpp#L316-L317
[9] https://github.com/bminor/binutils-gdb/blob/binutils-2_38-branch/include/opcode/riscv.h#L30-L42

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

Commit messages:
 - Okay, fixed.

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

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


From dholmes at openjdk.org  Fri Feb 17 05:31:11 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Feb 2023 05:31:11 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v5]
In-Reply-To: <QlSM_3RkD1KaachnGP-PFNJKqSg45GZ1L4qZl0s_19c=.dac73c44-d43d-4349-b423-172318b3962d@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <QlSM_3RkD1KaachnGP-PFNJKqSg45GZ1L4qZl0s_19c=.dac73c44-d43d-4349-b423-172318b3962d@github.com>
Message-ID: <hMOkBox0wiRhIal7maRRdpvMMgg9SHqRwYVpyIG5dLs=.af7a9322-f344-4c34-9f1e-4ae42f7da666@github.com>

On Thu, 16 Feb 2023 09:18:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
>> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
>> On macOS, sysctlbyname can be used.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not print idle state infos on Windows, print same MHz values for all proces only once

General approach seems okay. A couple of queries and nits.

Thanks.

src/hotspot/os/windows/os_windows.cpp line 1900:

> 1898: 
> 1899:   size_t sz_check = sizeof(PROCESSOR_POWER_INFORMATION) * (size_t)proc_count;
> 1900:   NTSTATUS status = ::CallNtPowerInformation(ProcessorInformation, NULL, 0, buf, (ULONG) buflen);

How is the caller supposed to know what size buffer to pass? Are they just supposed to guess and hope it is big enough??

src/hotspot/os/windows/os_windows.cpp line 1901:

> 1899:   size_t sz_check = sizeof(PROCESSOR_POWER_INFORMATION) * (size_t)proc_count;
> 1900:   NTSTATUS status = ::CallNtPowerInformation(ProcessorInformation, NULL, 0, buf, (ULONG) buflen);
> 1901:   int MaxMhz = -1, CurrentMhz = -1, MhzLimit = -1;

Nit: variable names should not start with Capital letters

src/hotspot/os/windows/os_windows.cpp line 1915:

> 1913:             CurrentMhz != (int) pppi->CurrentMhz ||
> 1914:             MhzLimit != (int) pppi->MhzLimit) {
> 1915:           same_vals_for_all_cpus = false;

You could break once this is false.

src/hotspot/os/windows/os_windows.cpp line 1919:

> 1917:       }
> 1918:       // avoid iteration in case buf is too small to hold all proc infos
> 1919:       if (sz_check > buflen) break;

In this case shouldn't the function have returned `STATUS_BUFFER_TOO_SMALL`?

src/hotspot/os/windows/os_windows.cpp line 1924:

> 1922: 
> 1923:     if (same_vals_for_all_cpus && MaxMhz != -1) {
> 1924:       st->print_cr("ProcessorInformation for all %d processors :", proc_count);

Nit: Processor Information

src/hotspot/os/windows/os_windows.cpp line 1931:

> 1929:     pppi = (PROCESSOR_POWER_INFORMATION*) buf;
> 1930:     for (int i = 0; i < proc_count; i++) {
> 1931:       st->print_cr("ProcessorInformation for processor %d", (int) pppi->Number);

Nit: Processor Information

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

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


From mbaesken at openjdk.org  Fri Feb 17 08:17:52 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 17 Feb 2023 08:17:52 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v6]
In-Reply-To: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
Message-ID: <9sXgm64E6wvYLyO1pozlM56H-NXO9dU0lZJAdT4bjMI=.be4d799e-98bf-4f81-9b29-da7170f3d8ef@github.com>

> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
> On macOS, sysctlbyname can be used.

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

  Rename variables, adjust output, add a break

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12403/files
  - new: https://git.openjdk.org/jdk/pull/12403/files/2811225e..439644e2

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

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

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


From mbaesken at openjdk.org  Fri Feb 17 08:17:52 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 17 Feb 2023 08:17:52 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v5]
In-Reply-To: <hMOkBox0wiRhIal7maRRdpvMMgg9SHqRwYVpyIG5dLs=.af7a9322-f344-4c34-9f1e-4ae42f7da666@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <QlSM_3RkD1KaachnGP-PFNJKqSg45GZ1L4qZl0s_19c=.dac73c44-d43d-4349-b423-172318b3962d@github.com>
 <hMOkBox0wiRhIal7maRRdpvMMgg9SHqRwYVpyIG5dLs=.af7a9322-f344-4c34-9f1e-4ae42f7da666@github.com>
Message-ID: <inpe9yOFYlRU_FKi7yJx_61otPcaRaBOjWl0VsnGukU=.786dddd4-faeb-449d-a346-6bc93349f156@github.com>

On Fri, 17 Feb 2023 05:17:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not print idle state infos on Windows, print same MHz values for all proces only once
>
> src/hotspot/os/windows/os_windows.cpp line 1915:
> 
>> 1913:             CurrentMhz != (int) pppi->CurrentMhz ||
>> 1914:             MhzLimit != (int) pppi->MhzLimit) {
>> 1915:           same_vals_for_all_cpus = false;
> 
> You could break once this is false.

Added a break.

> src/hotspot/os/windows/os_windows.cpp line 1924:
> 
>> 1922: 
>> 1923:     if (same_vals_for_all_cpus && MaxMhz != -1) {
>> 1924:       st->print_cr("ProcessorInformation for all %d processors :", proc_count);
> 
> Nit: Processor Information

I adjusted the output.

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

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


From mbaesken at openjdk.org  Fri Feb 17 08:27:18 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 17 Feb 2023 08:27:18 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v6]
In-Reply-To: <9sXgm64E6wvYLyO1pozlM56H-NXO9dU0lZJAdT4bjMI=.be4d799e-98bf-4f81-9b29-da7170f3d8ef@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <9sXgm64E6wvYLyO1pozlM56H-NXO9dU0lZJAdT4bjMI=.be4d799e-98bf-4f81-9b29-da7170f3d8ef@github.com>
Message-ID: <7IVqT4MR0jgYbRruCaIsR26VjlNxota2b7rAyiL26hU=.1349ca6f-8af3-4777-8cfb-e29946de6928@github.com>

On Fri, 17 Feb 2023 08:17:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
>> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
>> On macOS, sysctlbyname can be used.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename variables, adjust output, add a break

Hi David I adjusted the output, renamed some variables and added a break where you suggested.

> In this case shouldn't the function have returned STATUS_BUFFER_TOO_SMALL

I think this would be the case, but I was not sure so I added the check.

> How is the caller supposed to know what size buffer to pass? Are they just supposed to guess and hope it is big enough??

I think this is the same for most of the print_  functions from
src/hotspot/share/runtime/os.hpp
getting a buffer 'buf'  and a buf-length value, they are unfortunately not very specific on the size passed.

https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/os.hpp#L754

  // Print out system information; they are called by fatal error handler.
  // Output format may be different on different platforms.

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

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


From asotona at openjdk.org  Fri Feb 17 09:04:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:04:24 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v21]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <fcRYRRzJqPWm4kqsi45iMDVs_Cs30WGIjyFtFby44wU=.fd00552f-d34f-4bda-9d49-ddda4643da2e@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Option keys and values accessing pulled from API to implementation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/7a45ebd3..4d70fc2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=19-20

  Stats: 129 lines in 26 files changed: 8 ins; 58 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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


From asotona at openjdk.org  Fri Feb 17 09:15:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:15:39 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <xPfx_58QY7Q6bS96T1DgNiucx7Ks4urjMC4BxbjoN8A=.cb40548a-e80b-4948-8e94-310c922a3a66@github.com>

On Thu, 16 Feb 2023 10:56:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 93:
> 
>> 91:          * @return name of the node
>> 92:          */
>> 93:         public ConstantDesc name();
> 
> Not sure about the ConstantDesc here. Why is it better than String?

Type information allows nice rendering for some types in some structured text formats, while `ConstantDesc::toString` is a fallback.

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

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


From asotona at openjdk.org  Fri Feb 17 09:27:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:27:39 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <1G9rLfYBxfxcwmzgd7VDXnTfrW252lIui-9sWVAAhn0=.d3e5b0e6-66cc-4322-ae31-282954e9d3ca@github.com>

On Thu, 16 Feb 2023 11:00:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 563:
> 
>> 561:                       list("attributes", "attribute", clm.attributes().stream().map(Attribute::attributeName)))
>> 562:                 .with(constantPoolToTree(clm.constantPool(), verbosity))
>> 563:                 .with(attributesToTree(clm.attributes(), verbosity))
> 
> Is this ok? It seems we also add class attributes in the map node (see "attributes" map node).

Yes, the print structure does not exactly correspond to the Classfile API architecture, but rather to the classfile physical structure and it is partly similar to `javap` output.
The common tree structure has been reverse-designed from the desired visual representations in all supported text formats and in all verbosity levels.

> src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 83:
> 
>> 81:  * ConstantPool.
>> 82:  */
>> 83: public final class SplitConstantPool implements ConstantPoolBuilder {
> 
> Not sure the "Split" prefix carries any meaning? (perhaps a leftover from previous iterations?)

The "Split" represent a division between the original read-only constant pool and the new part with additional CP entries.

> src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java line 60:
> 
>> 58:     private static final Options options = new Options(Collections.emptyList());
>> 59: 
>> 60:     private TemporaryConstantPool() {};
> 
> If I understand correctly, this constant pool is just "fake" in the sense that it's a builder which creates constant pool entries w/o storing them anywhere. This seems to be used in places where e.g. we need to convert a ClassDesc to a ClassEntry, probably so that the implementation of e.g. attributes can be defined in terms of constant pool entries, even when "unbounded". E.g. this is a trick which avoids having completely different representations for bound and unbound elements - correct?

Yes, exactly :)

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

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


From asotona at openjdk.org  Fri Feb 17 09:33:44 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:33:44 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <nrZU8-0YNLR3zAiaiq60Uh-w53ekdwdvcHkZtzj-10I=.618b22fd-a859-496c-aa81-2eca315d63c3@github.com>

On Thu, 16 Feb 2023 14:24:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 649:
> 
>> 647:             if (parentMap == null)
>> 648:                 parentMap = new IdentityHashMap<>();
>> 649:             int[] table = parentMap.computeIfAbsent(parent, new Function<CodeAttribute, int[]>() {
> 
> Can use a lambda here?

I'll have to add relevant comment here.
There are many places in the Classfile API, which are on critical JDK bootstrap path in the follow-up integrations and using lambdas or method references would cause stack overflow during JDK bootstrap.
Using other words - these fragments cannot use lambdas as they suppose to generate lambdas for JDK ;)

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

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


From asotona at openjdk.org  Fri Feb 17 09:38:36 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 09:38:36 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <XdPsRS7sN9MC3gcIyTcIN3BhhfrgSjSZYnq1jC_pqc0=.aad91048-53be-4f19-a7fd-ed4e41ad5deb@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <XdPsRS7sN9MC3gcIyTcIN3BhhfrgSjSZYnq1jC_pqc0=.aad91048-53be-4f19-a7fd-ed4e41ad5deb@github.com>
Message-ID: <wZVyue5fQUUk7x0iSQ_jo5cYsWdNUkU3HZLuquJtz60=.1a6e9c36-0c55-4305-9f6c-653c7f9f8bb8@github.com>

On Thu, 16 Feb 2023 12:11:06 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 96:
> 
>> 94:      * @param <T> the type of the option value
>> 95:      */
>> 96:     <T> T optionValue(Classfile.Option.Key option);
> 
> This unconstrained type parameter will result in and implicit conversion to any type that the caller assigns it to, which might result in a `ClassCastException` if the caller gets the type wrong.
> 
> Is this intentional?
> 
> The same idiom is used in a few other places in the code.
> 
> Alternative solutions: 
> 
> * Convert `Key` to an ordinary class or sealed interface, and add a type parameter to it, for the value type. (Enums unfortunately don't support type parameters.)
> * Add a parameter the the method of type `Class<T>`.

Thanks for pointing it out.
I've re-visited the API re-accessing already provided options and found no relevant use case.
This method (and similar on other places), plus the `Classfile.Option.Key` will be pulled from API to the implementation.
Please let us know if there is a need to read option values from user perspective.

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

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


From msheppar at openjdk.org  Fri Feb 17 10:59:59 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 17 Feb 2023 10:59:59 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
Message-ID: <M2ZPlFDcazCXyxKYltg_KW7q8ZAkLkXyREZBg4A373c=.a5f4ddaf-3a19-4f96-a38f-21643e3f4086@github.com>

On Thu, 16 Feb 2023 16:49:09 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit line length to 80-ish characters

I don't think the NetworkInterface.h file should be dropped.
It is preferrable that typedef and struct decalarations remain in a header file rather than being merged into .c file.

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

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


From asotona at openjdk.org  Fri Feb 17 11:46:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 11:46:54 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v22]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <B3aI0vwyuZtX_GIQTL4ijhBzuHCY-WZOBoXb2TbSHTw=.ee3b2301-b981-4e12-a09b-afd6ebb014f2@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed PoolEntry::clone and ConstantPoolBuilder::maybeClone from API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/4d70fc2f..15b69a4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=20-21

  Stats: 59 lines in 9 files changed: 10 ins; 39 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

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


From asotona at openjdk.org  Fri Feb 17 11:46:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 11:46:58 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <AJgsunTEzUuzgdTQKiSBTXDrhs5_MmqNZWnSURk61AE=.b8e71cb6-1ccb-49f3-afda-d2a98f4ec701@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
 <WjPpEjQMu0JRMC50Ah6GbGziijbdSSS_EUGbSJ_gH2I=.bafee453-7bfc-444d-93eb-8d3b9258a2fd@github.com>
 <CXD_fqRhrtJW65rK0-TQaDVNIS3EGBXMZIQgKFrkQv0=.4d4b2608-ce7e-407b-9d88-2f4e9654e672@github.com>
 <3HZ_jmmtzk1RUgiUGwGudTaqvzEbFkla14T4EDKSjxU=.1fd22057-627c-42df-80a1-1c7c37486c4c@github.com>
 <AJgsunTEzUuzgdTQKiSBTXDrhs5_MmqNZWnSURk61AE=.b8e71cb6-1ccb-49f3-afda-d2a98f4ec701@github.com>
Message-ID: <tA0IGrEw21mC9OLiLyKjXtEif0OkVmTojTosrj3NQnY=.e1046af4-33d1-4141-b225-92778df56895@github.com>

On Thu, 16 Feb 2023 10:48:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> The main difference is that if the given entry is not directly applicable (when it comes from 3rd constant pool or when the pool is not shared during transformation) - a new or matching entry to the target pool is returned.
>> This is not a builder pattern, this is projection of an entry to the target CP and it also prevents duplicates.
>
> `maybeClone` is not the main avenue, it is rather a helper method and I'll look at details if it is necessary too expose it.

`ConstantPoolBuilder::maybeClone` and `PoolEntry::clone` have been pulled from API to implementation

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

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


From ihse at openjdk.org  Fri Feb 17 12:11:28 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 17 Feb 2023 12:11:28 GMT
Subject: RFR: JDK-8300531: MSVC CFlags look suspicious [v9]
In-Reply-To: <dSZuIK87NesGqJR5ZjDArPXTvd1-9gEuX8JjVYyzmgg=.761b9936-5b15-4772-bebd-300e75e066fb@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>
 <dSZuIK87NesGqJR5ZjDArPXTvd1-9gEuX8JjVYyzmgg=.761b9936-5b15-4772-bebd-300e75e066fb@github.com>
Message-ID: <qzesAELEZsrYiUsXyUyMFyPtdcQGGK_1irYRJwLqWEA=.4c6f4d80-741f-406c-9395-8ec23dc8d319@github.com>

On Thu, 16 Feb 2023 06:33:08 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> As a general comment, the bug title should be to the point. "Look suspicious" contains no information. It looks like you are changing the optimization level, so the bug title should reflect that.

I agree. But let me expand the point a bit: It is fully okay for an *issue in JBS* to have a title like "flags look sus". Bug reports can be vague and be as much about further research. But once the research is done, the bug should either be closed (if the research ended in "it's ok, no change needed"), or it should be retitled to describe the actual changes needed.

So the requirement to match PR and bug title is a good one, but we should be liberal with updating bug titles in JBS, when more knowledge about the problem has appeared.

And, as another general rule, if some code is still in the "research" phase, but you still want to open a PR, it should be opened as a draft. That way you clearly signal that you do not intend to integrate the changes as-is, but are looking for feedback on an incomplete fix.

So, an alternative to renaming the PR/JBS issue, is to move this PR to draft. And perhaps make it even clearer by renaming it "WIP: ....". That makes the bug impossible to integrate, and will give folks peace of mind of knowing that this won't suddenly be integrated without further discussion.

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

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


From asotona at openjdk.org  Fri Feb 17 13:25:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 13:25:52 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v23]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <wshKgaF_Q9nQz9zd4f0sjt-yf_YDkmAy2I9USi_P8bI=.3d0f930d-08f0-47c1-a239-7f6009c41c27@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - javadoc fix
 - renamed PoolEntry::poolEntries to ::width

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/15b69a4c..1bf62016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=21-22

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

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


From asotona at openjdk.org  Fri Feb 17 13:26:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 17 Feb 2023 13:26:50 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v15]
In-Reply-To: <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <hr8eti6ytvV05JFRr5hYLWy7yBla9mpI8vKKfaaFR-k=.a92f7bea-6400-4f95-a40c-d57192013f19@github.com>
 <hUvPqC4427nX8mcEcC5Tr90RFXAtmNigTxexY_Ujf04=.55b5e41d-afa7-4220-b13f-6fb0dd25dd0e@github.com>
Message-ID: <uRqvNOIr4t5EwOCfnTz6c-cWmL3iUOtlk3cvMEdqy60=.0e4955c3-e9b8-4602-b714-d76a703ab323@github.com>

On Thu, 9 Feb 2023 14:07:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AttributeElement.Kind removal (#48)
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/MethodHandleEntry.java line 40:
> 
>> 38: 
>> 39:     /**
>> 40:      * {@return the reference kind of this method handle}
> 
> Where are the constants that can be used to decode the MH kind? Perhaps a reference from the javadoc could be helpful.

Fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/constantpool/PoolEntry.java line 55:
> 
>> 53:      * {@return the number of constant pool slots this entry consumes}
>> 54:      */
>> 55:     int poolEntries();
> 
> maybe `width` ?

Yes, it sounds better. Fixed, thanks.

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

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


From erikj at openjdk.org  Fri Feb 17 14:29:50 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 17 Feb 2023 14:29:50 GMT
Subject: RFR: 8302226 failure_handler native.core should wait for coredump
 to finish [v2]
In-Reply-To: <2-fRnycvALxQrNO1Pw0oh0MUU8Xb3_4xmjSwI6PQzBM=.77e0dabf-82ed-4a6e-ad71-809a96939b82@github.com>
References: <5k6enBnRlLOZsW9Dp3NWLwiw-JeURwl-9omJht157vY=.dc8401f6-5b3d-4997-aee2-0003b1a01ab9@github.com>
 <2-fRnycvALxQrNO1Pw0oh0MUU8Xb3_4xmjSwI6PQzBM=.77e0dabf-82ed-4a6e-ad71-809a96939b82@github.com>
Message-ID: <RAve0WwTIc6wn5J3YGqideJcM8WeU5y6nQLzJVvcut8=.e053bc8a-8832-4fbb-bcc6-c9af86d90dd0@github.com>

On Mon, 13 Feb 2023 10:21:05 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

>> Update open/test/failure_handler/src/share/conf/(linux,mac).properties to handle core dumps more correctly.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add mac

Marked as reviewed by erikj (Reviewer).

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

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


From lujaniuk at openjdk.org  Fri Feb 17 15:11:51 2023
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Fri, 17 Feb 2023 15:11:51 GMT
Subject: Integrated: 8302226 failure_handler native.core should wait for
 coredump to finish
In-Reply-To: <5k6enBnRlLOZsW9Dp3NWLwiw-JeURwl-9omJht157vY=.dc8401f6-5b3d-4997-aee2-0003b1a01ab9@github.com>
References: <5k6enBnRlLOZsW9Dp3NWLwiw-JeURwl-9omJht157vY=.dc8401f6-5b3d-4997-aee2-0003b1a01ab9@github.com>
Message-ID: <JTcs0_D8kIKIwWRrQAB8CQx_OWmbcm6B6PlwmTP_cH4=.8130fc9b-4ee7-4542-95f0-e7549f37bed7@github.com>

On Fri, 10 Feb 2023 18:19:01 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> Update open/test/failure_handler/src/share/conf/(linux,mac).properties to handle core dumps more correctly.

This pull request has now been integrated.

Changeset: 6120319a
Author:    Ludvig Janiuk <lujaniuk at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6120319afdba98b5ff547b870a0260479e8b683c
Stats:     10 lines in 2 files changed: 6 ins; 0 del; 4 mod

8302226: failure_handler native.core should wait for coredump to finish

Reviewed-by: erikj

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

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


From mcimadamore at openjdk.org  Fri Feb 17 17:25:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Feb 2023 17:25:55 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <1G9rLfYBxfxcwmzgd7VDXnTfrW252lIui-9sWVAAhn0=.d3e5b0e6-66cc-4322-ae31-282954e9d3ca@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
 <1G9rLfYBxfxcwmzgd7VDXnTfrW252lIui-9sWVAAhn0=.d3e5b0e6-66cc-4322-ae31-282954e9d3ca@github.com>
Message-ID: <9Q436PkBJ4HIYF1ZSYJz_gEL3A1qfpjZKWKc82NVD6k=.7ce49423-395b-430a-9aa5-111106b77937@github.com>

On Fri, 17 Feb 2023 09:20:21 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 563:
>> 
>>> 561:                       list("attributes", "attribute", clm.attributes().stream().map(Attribute::attributeName)))
>>> 562:                 .with(constantPoolToTree(clm.constantPool(), verbosity))
>>> 563:                 .with(attributesToTree(clm.attributes(), verbosity))
>> 
>> Is this ok? It seems we also add class attributes in the map node (see "attributes" map node).
>
> Yes, the print structure does not exactly correspond to the Classfile API architecture, but rather to the classfile physical structure and it is partly similar to `javap` output.
> The common tree structure has been reverse-designed from the desired visual representations in all supported text formats and in all verbosity levels.

Not sure I get this. It seems to me that the same attributes are being printed twice. But, perhaps, the first pass only creates a list with the attribute _names_ and then there is a later pass which print the attributes in full?

>> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 649:
>> 
>>> 647:             if (parentMap == null)
>>> 648:                 parentMap = new IdentityHashMap<>();
>>> 649:             int[] table = parentMap.computeIfAbsent(parent, new Function<CodeAttribute, int[]>() {
>> 
>> Can use a lambda here?
>
> I'll have to add relevant comment here.
> There are many places in the Classfile API, which are on critical JDK bootstrap path in the follow-up integrations and using lambdas or method references would cause stack overflow during JDK bootstrap.
> Using other words - these fragments cannot use lambdas as they suppose to generate lambdas for JDK ;)

I suspect that was the case :-)

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

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


From djelinski at openjdk.org  Fri Feb 17 20:54:32 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 17 Feb 2023 20:54:32 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <ZtaW6W021evEqiZFkOBv956WjgTAIPlUSk6hb9RNryY=.7cd9c1a3-6566-4fbb-974e-745444807a64@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
 <njL-lKEZ7z886PvCv4sULPOpdI0iwe-yAlsaEmTNvgY=.5ffd751e-8b8e-4dbc-9cc4-49135cfdd14c@github.com>
 <1en36lUgplk03paOtfrxk-Aoiop5Toe2Sd7oVcx74K4=.ef33f250-b03a-44d8-adcc-1e3dff6b55dc@github.com>
 <ZTK_RPj42NlKZXGbE7jpBLr5CLG-u3byte3KM1fU1-A=.e2d89b9b-f524-4aff-b330-d46c95d6894c@github.com>
 <KXOgOmZJcNXej2bqOW8i8jffiOXgtMi42tuZ4U1Jgkw=.3f05fe94-8a9c-463d-820c-7e46ea92c56c@github.com>
 <uLpe7n8lEcuqTgXi1oh3csHwAdKuV5WvwPYsBB252O4=.97ef5c2f-6ddc-468b-969f-e7bdf8168a0b@github.com>
 <ZtaW6W021evEqiZFkOBv956WjgTAIPlUSk6hb9RNryY=.7cd9c1a3-6566-4fbb-974e-745444807a64@github.com>
Message-ID: <iajubMV_C7bgMEIojOXyzuKnkrYM2erec1btol-I2VU=.6d253f15-0163-471b-80f9-525c62de384c@github.com>

On Thu, 16 Feb 2023 21:48:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Note that the new code doesn't attempt to sort anything. If it happens to be sorted by LUID, that's the underlying API at work. The MS docs don't say anything about ordering, so this is probably an implementation detail and I wouldn't assume it will always be true.
>> 
>> I'm still running jdk_net, but I can already see that test failing on my machine. Though it has a different error:
>> 
>> 
>> java.io.IOException: Network interface not configured for IPv4
>> 	at java.base/sun.nio.ch.DatagramChannelImpl.setOption(DatagramChannelImpl.java:389)
>> 	at java.base/sun.nio.ch.DatagramSocketAdaptor.setOption(DatagramSocketAdaptor.java:431)
>> 	at java.base/java.net.DatagramSocket.setOption(DatagramSocket.java:1207)
>> 	at OptionsTest.test(OptionsTest.java:155)
>> 	at OptionsTest.doMulticastSocketTests(OptionsTest.java:235)
>> 	at OptionsTest.main(OptionsTest.java:337)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:125)
>> 	at java.base/java.lang.Thread.run(Thread.java:1623)
>> 
>> 
>> So I think when picking the interface to use for the test, we need to also check that isUp = true and that the list of IP addresses contains at least one IPv4 address.
>
> Though it's more complicated than that. Some machines may have both IPv6 and IPv4, some machine may only have IPv4, and some machine may only have IPv6. I haven't looked at the test yet, but picking up the right interface on the various platforms has always been an issue for our tests.

So,, apparently this is a Windows feature. [Older socket implementation](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c#L1350) had an explicit check for addresses bound to an interface, and only interfaces with associated addresses could be used for multicasting.

This needs to be fixed in the test. Can you add a check for addresses to `OptionsTest.getNetworkInterface`?

Beyond that, I'm fine with an implementation that unconditionally returns `true`.

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

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


From djelinski at openjdk.org  Fri Feb 17 21:01:28 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 17 Feb 2023 21:01:28 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <YrqcagiZH-PmknZqRyWNS0odIVn4mynZYVuLX6-WnHM=.908a9ca0-ec91-4160-8cb9-59af153f0ac9@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
 <YrqcagiZH-PmknZqRyWNS0odIVn4mynZYVuLX6-WnHM=.908a9ca0-ec91-4160-8cb9-59af153f0ac9@github.com>
Message-ID: <DzCziVgHpcWFLUzE6OqCVlKsgnwhPhR29nbc78NUO74=.168a43ee-da3f-4ab8-85bf-d39926b74875@github.com>

On Thu, 16 Feb 2023 17:56:58 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> src/java.base/windows/native/libnet/NetworkInterface.c line 72:
>> 
>>> 70:         return FALSE;
>>> 71:     }
>>> 72:     if (GetAnycastIpAddressTable(addrFamily, anyAddrs) != NO_ERROR) {
>> 
>> Were the anycast addresses covered by the existing code, or is this a functional change?
>
> For the IPv6 code, this should be the same as before. See getAddrsFromAdapter in the original code, which enumerates the unicast addresses first and then does the anycast addresses.
> 
> For IPv4, I'm not sure. The MS docs for GetIpAddrTable don't say, and I don't have any systems where I could determine it experimentally.

I tried creating an anycast address using the [CreateAnycastIpAddressEntry API](https://learn.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-createanycastipaddressentry) and the [New-NetIPAddress Powershell command](https://learn.microsoft.com/en-us/powershell/module/nettcpip/new-netipaddress?view=windowsserver2022-ps), but I only managed to lock myself out from a VM; creating the address failed with ERROR_NOT_SUPPORTED, and the powershell command additionally disabled DHCP on the selected interface.

With that in mind I'm fine with the code in its current form. We may revisit the issue if and when someone figures out how to add an anycast address.

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

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


From jcking at openjdk.org  Sat Feb 18 18:08:56 2023
From: jcking at openjdk.org (Justin King)
Date: Sat, 18 Feb 2023 18:08:56 GMT
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++ [v2]
In-Reply-To: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
Message-ID: <bVU-Fd84lmkupa7GxX04ocHJFYpncKj5zjNoD3KLSz4=.964cd3ca-17b2-4952-a376-1dadd2376bb9@github.com>

> Update build-related infrastructure to support building with ASan under Microsoft Visual C++.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Update based on review
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12580/files
  - new: https://git.openjdk.org/jdk/pull/12580/files/9cd8e24e..a07f7cf0

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

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

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


From jcking at openjdk.org  Sat Feb 18 18:08:56 2023
From: jcking at openjdk.org (Justin King)
Date: Sat, 18 Feb 2023 18:08:56 GMT
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++ [v2]
In-Reply-To: <eadkDZehA1lOHzmAMJWXp4ng_sMGR68Fjj9UzO1_x6g=.6681519d-b1ec-4503-ba57-d7dfa1cb0668@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
 <eadkDZehA1lOHzmAMJWXp4ng_sMGR68Fjj9UzO1_x6g=.6681519d-b1ec-4503-ba57-d7dfa1cb0668@github.com>
Message-ID: <sNJ9jR96aC5f4BVh14jwMBQB_WlqOz4AWAN0kYKxgj4=.2a61ef82-52ac-4614-ac80-2a6b34d99c78@github.com>

On Thu, 16 Feb 2023 16:27:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Justin King has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update based on review
>>   
>>   Signed-off-by: Justin King <jcking at google.com>
>
> make/autoconf/jdk-options.m4 line 427:
> 
>> 425:       ],
>> 426:       IF_ENABLED: [
>> 427:         ASAN_CFLAGS="-fsanitize=address"
> 
> It seems like more of a coincidence than a obvious fact to base the design on that `-fsanitize=address` happens to work on both ms cl.exe and gcc/clang.
> 
> Maybe this is the herald of a new age of compiler switches getting cross-compiler standard names (let's hope!), but I think it still makes more sense to not share CFLAGS between microsoft and clang/gcc.
> 
> Or, more concretely: There is no need to define `ASAN_CFLAGS` and `ASAN_LDFLAGS` outside the two toolchain specific clauses.

Updated to what I think you were requesting. PTAL.

> make/autoconf/jdk-options.m4 line 438:
> 
>> 436:         elif test "x$TOOLCHAIN_TYPE" = "xmicrosoft"; then
>> 437:           # MSVC produces a warning if you pass -fsanitize=address to the linker.
>> 438:           ASAN_CFLAGS="$ASAN_CFLAGS -Oy-"
> 
> What is the purpose of `/Oy-`? Can you explain it in a short comment?

Added a comment.

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

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


From jcking at openjdk.org  Sat Feb 18 18:21:44 2023
From: jcking at openjdk.org (Justin King)
Date: Sat, 18 Feb 2023 18:21:44 GMT
Subject: RFR: JDK-8300531: Update MSVC optimization flags to match
 GCC/Clang [v10]
In-Reply-To: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
Message-ID: <AcCkC9tstPkSOX-u5LOxV5bsrVUUVifQzFvhSKg5e6M=.02e02d1f-a4b2-48c4-a2b4-6d3ffc4ad328@github.com>

> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Add comments clarifying -Oy-
  
  Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12073/files
  - new: https://git.openjdk.org/jdk/pull/12073/files/53a2ef3a..af74073c

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

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

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


From jcking at openjdk.org  Sat Feb 18 18:21:44 2023
From: jcking at openjdk.org (Justin King)
Date: Sat, 18 Feb 2023 18:21:44 GMT
Subject: RFR: JDK-8300531: Update MSVC optimization flags to match
 GCC/Clang [v9]
In-Reply-To: <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <qfed0l5EXoEmkEtE4d5xCypaKBTsvsHXgCqBiLRqIwk=.426d60c1-f1c4-4171-80bf-09391dc3c322@github.com>
Message-ID: <OohpIMc0Je75FwBmtjswA8sKVMMMSWgtKW9PLnQwCm0=.955aaa9c-0017-40a8-8723-d45dacf1047e@github.com>

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

>> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert usage of /GR-
>   
>   Signed-off-by: Justin King <jcking at google.com>

Okay I updated this change title to be more specific, sorry about that. Just optimization-related flags. I punted on disabling RTTI to [JDK-8302817](https://bugs.openjdk.org/browse/JDK-8302817) as I cannot pinpoint the failure, it seems related to DbgHelp or DbgEng.

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

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


From jcking at openjdk.org  Sat Feb 18 18:26:25 2023
From: jcking at openjdk.org (Justin King)
Date: Sat, 18 Feb 2023 18:26:25 GMT
Subject: RFR: JDK-8300531: Update MSVC optimization flags to match
 GCC/Clang [v10]
In-Reply-To: <AcCkC9tstPkSOX-u5LOxV5bsrVUUVifQzFvhSKg5e6M=.02e02d1f-a4b2-48c4-a2b4-6d3ffc4ad328@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <AcCkC9tstPkSOX-u5LOxV5bsrVUUVifQzFvhSKg5e6M=.02e02d1f-a4b2-48c4-a2b4-6d3ffc4ad328@github.com>
Message-ID: <30CQ_6J-LFxiwXJzMpTm-CFItchyk5GqqlSkxZROVQo=.dd3440b0-4e2b-42f7-ac59-2e8515c06f8e@github.com>

On Sat, 18 Feb 2023 18:21:44 GMT, Justin King <jcking at openjdk.org> wrote:

>> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments clarifying -Oy-
>   
>   Signed-off-by: Justin King <jcking at google.com>

This change ensures MSVC is similar to GCC/Clang in terms of optimization flags, at least in spirit. It also applies the equivalent of `-fno-omit-frame-pointer` to MSVC (`-Oy-`). Binary size is not significantly affected. The main difference is MSVC will prefer speed over size when generating code, and will try to prefer intrinsic versions of builtins rather than emitting function calls.

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

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


From ihse at openjdk.org  Sat Feb 18 21:34:26 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 18 Feb 2023 21:34:26 GMT
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++ [v2]
In-Reply-To: <bVU-Fd84lmkupa7GxX04ocHJFYpncKj5zjNoD3KLSz4=.964cd3ca-17b2-4952-a376-1dadd2376bb9@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
 <bVU-Fd84lmkupa7GxX04ocHJFYpncKj5zjNoD3KLSz4=.964cd3ca-17b2-4952-a376-1dadd2376bb9@github.com>
Message-ID: <u35TIWrQDsYwoSqJ5sYzbbZIOh3l7McgnV-wlPUDNTo=.3997a1c4-2f2b-4cea-ab6e-a92709ae82f4@github.com>

On Sat, 18 Feb 2023 18:08:56 GMT, Justin King <jcking at openjdk.org> wrote:

>> Update build-related infrastructure to support building with ASan under Microsoft Visual C++.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update based on review
>   
>   Signed-off-by: Justin King <jcking at google.com>

Marked as reviewed by ihse (Reviewer).

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

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


From ihse at openjdk.org  Sat Feb 18 21:34:28 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 18 Feb 2023 21:34:28 GMT
Subject: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++ [v2]
In-Reply-To: <sNJ9jR96aC5f4BVh14jwMBQB_WlqOz4AWAN0kYKxgj4=.2a61ef82-52ac-4614-ac80-2a6b34d99c78@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
 <eadkDZehA1lOHzmAMJWXp4ng_sMGR68Fjj9UzO1_x6g=.6681519d-b1ec-4503-ba57-d7dfa1cb0668@github.com>
 <sNJ9jR96aC5f4BVh14jwMBQB_WlqOz4AWAN0kYKxgj4=.2a61ef82-52ac-4614-ac80-2a6b34d99c78@github.com>
Message-ID: <pnJloqq095suTdzptA6KR6xr1YxFf_f2j0rY-sVe4gg=.b7e84e01-f6d9-43d6-b75b-67a88cf7bf5c@github.com>

On Sat, 18 Feb 2023 18:03:32 GMT, Justin King <jcking at openjdk.org> wrote:

>> make/autoconf/jdk-options.m4 line 427:
>> 
>>> 425:       ],
>>> 426:       IF_ENABLED: [
>>> 427:         ASAN_CFLAGS="-fsanitize=address"
>> 
>> It seems like more of a coincidence than a obvious fact to base the design on that `-fsanitize=address` happens to work on both ms cl.exe and gcc/clang.
>> 
>> Maybe this is the herald of a new age of compiler switches getting cross-compiler standard names (let's hope!), but I think it still makes more sense to not share CFLAGS between microsoft and clang/gcc.
>> 
>> Or, more concretely: There is no need to define `ASAN_CFLAGS` and `ASAN_LDFLAGS` outside the two toolchain specific clauses.
>
> Updated to what I think you were requesting. PTAL.

Yes, indeed. Thanks!

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

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


From ihse at openjdk.org  Sat Feb 18 21:38:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sat, 18 Feb 2023 21:38:25 GMT
Subject: RFR: JDK-8300531: Update MSVC optimization flags to match
 GCC/Clang [v10]
In-Reply-To: <AcCkC9tstPkSOX-u5LOxV5bsrVUUVifQzFvhSKg5e6M=.02e02d1f-a4b2-48c4-a2b4-6d3ffc4ad328@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <AcCkC9tstPkSOX-u5LOxV5bsrVUUVifQzFvhSKg5e6M=.02e02d1f-a4b2-48c4-a2b4-6d3ffc4ad328@github.com>
Message-ID: <0MaN7jVQAxBVba1602vY2CEZnaHTya-zOLMFzFl7A3A=.d4b4c052-9a4b-48ac-ba5a-225dce0b42fc@github.com>

On Sat, 18 Feb 2023 18:21:44 GMT, Justin King <jcking at openjdk.org> wrote:

>> Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments clarifying -Oy-
>   
>   Signed-off-by: Justin King <jcking at google.com>

The new title is showing much clearer what you want to achieve, thanks for that. But I'd like to re-iterate what Erik said early on:

> Changing the global optimization flags is a pretty big and potentially intrusive change. [...] I don't think making the number after the O in the flags match what we use for other compilers is motivation enough to warrant a change like this. 

That is, just making the flags "match" is not motivation enough to accept such a change. This needs to be thoroughly tested, and then communicated and discussed with the wider JDK community, including but not limited to, engineers specifically involved in performance testing, evaluation and improvements.

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

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


From jcking at google.com  Sun Feb 19 18:12:29 2023
From: jcking at google.com (Justin King)
Date: Sun, 19 Feb 2023 10:12:29 -0800
Subject: RFR: JDK-8300531: Update MSVC optimization flags to match
 GCC/Clang [v10]
In-Reply-To: <0MaN7jVQAxBVba1602vY2CEZnaHTya-zOLMFzFl7A3A=.d4b4c052-9a4b-48ac-ba5a-225dce0b42fc@github.com>
References: <whz8w1EFvidW5MmwKpGbGOx04HKc1kX4xgAruhh9J9A=.177e8308-c105-4178-b2d2-1e0a07bac927@github.com>
 <AcCkC9tstPkSOX-u5LOxV5bsrVUUVifQzFvhSKg5e6M=.02e02d1f-a4b2-48c4-a2b4-6d3ffc4ad328@github.com>
 <0MaN7jVQAxBVba1602vY2CEZnaHTya-zOLMFzFl7A3A=.d4b4c052-9a4b-48ac-ba5a-225dce0b42fc@github.com>
Message-ID: <CAEdz=WVFSgUqreKiF-W_wMbjZ8eBkeqH85LFw0YK01z8dw80_w@mail.gmail.com>

I'll work on some benchmark comparisons.

On Sat, Feb 18, 2023, 1:38 PM Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> On Sat, 18 Feb 2023 18:21:44 GMT, Justin King <jcking at openjdk.org> wrote:
>
> >> Update MSVC CFlags to be more consistent with other compilers. Also
> disables RTTI in a simliar manner to GCC/Clang for the JVM.
> >
> > Justin King has updated the pull request incrementally with one
> additional commit since the last revision:
> >
> >   Add comments clarifying -Oy-
> >
> >   Signed-off-by: Justin King <jcking at google.com>
>
> The new title is showing much clearer what you want to achieve, thanks for
> that. But I'd like to re-iterate what Erik said early on:
>
> > Changing the global optimization flags is a pretty big and potentially
> intrusive change. [...] I don't think making the number after the O in the
> flags match what we use for other compilers is motivation enough to warrant
> a change like this.
>
> That is, just making the flags "match" is not motivation enough to accept
> such a change. This needs to be thoroughly tested, and then communicated
> and discussed with the wider JDK community, including but not limited to,
> engineers specifically involved in performance testing, evaluation and
> improvements.
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12073
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230219/7d869220/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3999 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230219/7d869220/smime.p7s>

From mbaesken at openjdk.org  Mon Feb 20 08:06:30 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 20 Feb 2023 08:06:30 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v5]
In-Reply-To: <hMOkBox0wiRhIal7maRRdpvMMgg9SHqRwYVpyIG5dLs=.af7a9322-f344-4c34-9f1e-4ae42f7da666@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <QlSM_3RkD1KaachnGP-PFNJKqSg45GZ1L4qZl0s_19c=.dac73c44-d43d-4349-b423-172318b3962d@github.com>
 <hMOkBox0wiRhIal7maRRdpvMMgg9SHqRwYVpyIG5dLs=.af7a9322-f344-4c34-9f1e-4ae42f7da666@github.com>
Message-ID: <4tGBua7p_pWGKaFQNws4K30AjQtm2Mw6kG4k_B3h2LA=.8c738745-a0d9-4a8a-bd8d-531e210d83d2@github.com>

On Fri, 17 Feb 2023 05:21:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not print idle state infos on Windows, print same MHz values for all proces only once
>
> src/hotspot/os/windows/os_windows.cpp line 1901:
> 
>> 1899:   size_t sz_check = sizeof(PROCESSOR_POWER_INFORMATION) * (size_t)proc_count;
>> 1900:   NTSTATUS status = ::CallNtPowerInformation(ProcessorInformation, NULL, 0, buf, (ULONG) buflen);
>> 1901:   int MaxMhz = -1, CurrentMhz = -1, MhzLimit = -1;
> 
> Nit: variable names should not start with Capital letters

I adjusted the variable names.

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

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


From gdams at openjdk.org  Mon Feb 20 14:30:08 2023
From: gdams at openjdk.org (George Adams)
Date: Mon, 20 Feb 2023 14:30:08 GMT
Subject: RFR: 8302879: doc/building.md update link to jtreg builds
Message-ID: <25utvcF-Iem-aKljrFge3EbP9IZPNKwDguXDvA-wGQE=.980dee95-4ee9-4740-bbf7-847b11cbf223@github.com>

The Eclipse Adoptium project recently moved its CI from ci.adoptopenjdk.net to ci.adoptium.net. The link to jtreg builds needs updating

See https://github.com/adoptium/infrastructure/issues/2932 for more context

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

Commit messages:
 - 8302879: doc/building.md update link to jtreg builds

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

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


From sgehwolf at openjdk.org  Mon Feb 20 16:37:25 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 20 Feb 2023 16:37:25 GMT
Subject: RFR: 8302879: doc/building.md update link to jtreg builds
In-Reply-To: <25utvcF-Iem-aKljrFge3EbP9IZPNKwDguXDvA-wGQE=.980dee95-4ee9-4740-bbf7-847b11cbf223@github.com>
References: <25utvcF-Iem-aKljrFge3EbP9IZPNKwDguXDvA-wGQE=.980dee95-4ee9-4740-bbf7-847b11cbf223@github.com>
Message-ID: <tPIVACOfuiSNxJ4Ptjyt13SCGrFGhedqyOgXblt1rnM=.2f593448-dd11-4154-82a1-d201cc914481@github.com>

On Mon, 20 Feb 2023 14:22:40 GMT, George Adams <gdams at openjdk.org> wrote:

> The Eclipse Adoptium project recently moved its CI from ci.adoptopenjdk.net to ci.adoptium.net. The link to jtreg builds needs updating
> 
> See https://github.com/adoptium/infrastructure/issues/2932 for more context

Looks fine to me.

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

Marked as reviewed by sgehwolf (Reviewer).

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


From jcking at openjdk.org  Mon Feb 20 18:40:35 2023
From: jcking at openjdk.org (Justin King)
Date: Mon, 20 Feb 2023 18:40:35 GMT
Subject: Integrated: JDK-8302599: Extend ASan support to Microsoft Visual C++
In-Reply-To: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
References: <1nwAB0fpjuwJFXWcQJK7d3IV6gL9BzUIHyg4JNqGXyU=.7f3b76b6-c2ec-43f2-bcf1-eed8beb53f94@github.com>
Message-ID: <61UiFTBiCMV9574BETPVlI1yczAGvq559CCwT4THeN0=.6586ea80-bfa1-427b-8904-67a1a313a4d0@github.com>

On Wed, 15 Feb 2023 17:53:49 GMT, Justin King <jcking at openjdk.org> wrote:

> Update build-related infrastructure to support building with ASan under Microsoft Visual C++.

This pull request has now been integrated.

Changeset: 0bf3a53e
Author:    Justin King <jcking at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bf3a53e01818aca5e365ee7275e567aad0273cc
Stats:     24 lines in 2 files changed: 17 ins; 0 del; 7 mod

8302599: Extend ASan support to Microsoft Visual C++

Reviewed-by: erikj, stuefe, ihse

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

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


From clanger at openjdk.org  Mon Feb 20 21:57:24 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 20 Feb 2023 21:57:24 GMT
Subject: RFR: 8302879: doc/building.md update link to jtreg builds
In-Reply-To: <25utvcF-Iem-aKljrFge3EbP9IZPNKwDguXDvA-wGQE=.980dee95-4ee9-4740-bbf7-847b11cbf223@github.com>
References: <25utvcF-Iem-aKljrFge3EbP9IZPNKwDguXDvA-wGQE=.980dee95-4ee9-4740-bbf7-847b11cbf223@github.com>
Message-ID: <R4zai8Ted6YL5W7Bh7cGziF1oHGIfGK6lRBkUmNhqlE=.15b78503-f1c7-4e62-9619-91ae42b48909@github.com>

On Mon, 20 Feb 2023 14:22:40 GMT, George Adams <gdams at openjdk.org> wrote:

> The Eclipse Adoptium project recently moved its CI from ci.adoptopenjdk.net to ci.adoptium.net. The link to jtreg builds needs updating
> 
> See https://github.com/adoptium/infrastructure/issues/2932 for more context

Marked as reviewed by clanger (Reviewer).

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

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


From gdams at openjdk.org  Mon Feb 20 21:57:25 2023
From: gdams at openjdk.org (George Adams)
Date: Mon, 20 Feb 2023 21:57:25 GMT
Subject: RFR: 8302879: doc/building.md update link to jtreg builds
In-Reply-To: <tPIVACOfuiSNxJ4Ptjyt13SCGrFGhedqyOgXblt1rnM=.2f593448-dd11-4154-82a1-d201cc914481@github.com>
References: <25utvcF-Iem-aKljrFge3EbP9IZPNKwDguXDvA-wGQE=.980dee95-4ee9-4740-bbf7-847b11cbf223@github.com>
 <tPIVACOfuiSNxJ4Ptjyt13SCGrFGhedqyOgXblt1rnM=.2f593448-dd11-4154-82a1-d201cc914481@github.com>
Message-ID: <tr8S_pxE23J9WklMw8zEqOEirJIH-Cn3pl6MgdPcRM4=.82f59cb1-390c-4ef3-b2f3-673922c2ae8d@github.com>

On Mon, 20 Feb 2023 16:34:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The Eclipse Adoptium project recently moved its CI from ci.adoptopenjdk.net to ci.adoptium.net. The link to jtreg builds needs updating
>> 
>> See https://github.com/adoptium/infrastructure/issues/2932 for more context
>
> Looks fine to me.

@jerboaa are you happy to sponsor?

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

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


From clanger at openjdk.org  Mon Feb 20 22:02:33 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 20 Feb 2023 22:02:33 GMT
Subject: RFR: 8302879: doc/building.md update link to jtreg builds
In-Reply-To: <tPIVACOfuiSNxJ4Ptjyt13SCGrFGhedqyOgXblt1rnM=.2f593448-dd11-4154-82a1-d201cc914481@github.com>
References: <25utvcF-Iem-aKljrFge3EbP9IZPNKwDguXDvA-wGQE=.980dee95-4ee9-4740-bbf7-847b11cbf223@github.com>
 <tPIVACOfuiSNxJ4Ptjyt13SCGrFGhedqyOgXblt1rnM=.2f593448-dd11-4154-82a1-d201cc914481@github.com>
Message-ID: <4v7YUDVWIKpXswfak4rMw6tQzkHuBROld47sSrIA-vw=.75bd5c13-b904-44e6-b413-b9ef883c968e@github.com>

On Mon, 20 Feb 2023 16:34:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The Eclipse Adoptium project recently moved its CI from ci.adoptopenjdk.net to ci.adoptium.net. The link to jtreg builds needs updating
>> 
>> See https://github.com/adoptium/infrastructure/issues/2932 for more context
>
> Looks fine to me.

> @jerboaa are you happy to sponsor?

I am. Change is trivial and GHA errors can't be related. It's also not exactly touching the build system, although PR is labeled build.

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

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


From gdams at openjdk.org  Mon Feb 20 22:02:35 2023
From: gdams at openjdk.org (George Adams)
Date: Mon, 20 Feb 2023 22:02:35 GMT
Subject: Integrated: 8302879: doc/building.md update link to jtreg builds
In-Reply-To: <25utvcF-Iem-aKljrFge3EbP9IZPNKwDguXDvA-wGQE=.980dee95-4ee9-4740-bbf7-847b11cbf223@github.com>
References: <25utvcF-Iem-aKljrFge3EbP9IZPNKwDguXDvA-wGQE=.980dee95-4ee9-4740-bbf7-847b11cbf223@github.com>
Message-ID: <GmUJPvtDPcskGjfN3587ILbvtXs6bG_eygnamdKaKYc=.0ec6d759-ecc3-41f0-bf3b-9766f62c8082@github.com>

On Mon, 20 Feb 2023 14:22:40 GMT, George Adams <gdams at openjdk.org> wrote:

> The Eclipse Adoptium project recently moved its CI from ci.adoptopenjdk.net to ci.adoptium.net. The link to jtreg builds needs updating
> 
> See https://github.com/adoptium/infrastructure/issues/2932 for more context

This pull request has now been integrated.

Changeset: bb3dfd6a
Author:    George Adams <gdams at openjdk.org>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb3dfd6adbb58871bc7238107ed254831b22d48b
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8302879: doc/building.md update link to jtreg builds

Reviewed-by: sgehwolf, clanger

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

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


From dholmes at openjdk.org  Tue Feb 21 00:45:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Feb 2023 00:45:29 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v6]
In-Reply-To: <9sXgm64E6wvYLyO1pozlM56H-NXO9dU0lZJAdT4bjMI=.be4d799e-98bf-4f81-9b29-da7170f3d8ef@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <9sXgm64E6wvYLyO1pozlM56H-NXO9dU0lZJAdT4bjMI=.be4d799e-98bf-4f81-9b29-da7170f3d8ef@github.com>
Message-ID: <zfcMt9AP7fLmIkxSovtVObsVMmCtrj9F3LRwXr2Z7fs=.9fdb70f8-5210-41cd-a0eb-7fcf16f26590@github.com>

On Fri, 17 Feb 2023 08:17:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
>> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
>> On macOS, sysctlbyname can be used.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename variables, adjust output, add a break

I'm still a little dubious about the buffer size check but lets see how this goes.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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


From mbaesken at openjdk.org  Tue Feb 21 08:18:30 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 21 Feb 2023 08:18:30 GMT
Subject: RFR: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows [v6]
In-Reply-To: <9sXgm64E6wvYLyO1pozlM56H-NXO9dU0lZJAdT4bjMI=.be4d799e-98bf-4f81-9b29-da7170f3d8ef@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
 <9sXgm64E6wvYLyO1pozlM56H-NXO9dU0lZJAdT4bjMI=.be4d799e-98bf-4f81-9b29-da7170f3d8ef@github.com>
Message-ID: <JNOgSrCnRu_zYyBGyPmJMVWZkSxyZ1agt-1WcYn73wk=.bbe75655-278a-44e7-b30a-fc32a1d6f72a@github.com>

On Fri, 17 Feb 2023 08:17:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
>> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
>> On macOS, sysctlbyname can be used.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename variables, adjust output, add a break

Hi David and Lutz, thanks for the reviews.

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

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


From mbaesken at openjdk.org  Tue Feb 21 08:21:42 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 21 Feb 2023 08:21:42 GMT
Subject: Integrated: JDK-8301661: Enhance os::pd_print_cpu_info on macOS and
 Windows
In-Reply-To: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
References: <Jkjb-fGh8YaedWAl_mg3JRzhLV1Se32VluqbM0mwNVw=.5a624a28-6d74-49f8-89fd-9fd5b082fdcf@github.com>
Message-ID: <mTP5lGeVlJMBat-jLx7uO8ZNoLnxBQr7--xwoqWOKAY=.1a388bcc-2f67-47d2-bb0c-15f32ab70aab@github.com>

On Fri, 3 Feb 2023 08:25:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Enhance os::pd_print_cpu_info on macOS and Windows by information about CPU frequency and caches.
> On Windows , this info can be obtained by the Processor Power Information API or "powerbase" (CallNtPowerInformation , see https://learn.microsoft.com/en-us/windows/win32/api/powerbase/nf-powerbase-callntpowerinformation ); this is available since Windows Server 2003/XP.
> On macOS, sysctlbyname can be used.

This pull request has now been integrated.

Changeset: 91456703
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9145670354c41381614877aa71895dc2bd5cce9d
Stats:     87 lines in 3 files changed: 84 ins; 0 del; 3 mod

8301661: Enhance os::pd_print_cpu_info on macOS and Windows

Reviewed-by: ihse, lucy, dholmes

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

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


From jcking at openjdk.org  Tue Feb 21 16:50:19 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 21 Feb 2023 16:50:19 GMT
Subject: RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan
Message-ID: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>

Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots of warnings.

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

Commit messages:
 - Add -debug to LDFLAGS under MSVC with ASan

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

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


From jcking at openjdk.org  Tue Feb 21 16:50:20 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 21 Feb 2023 16:50:20 GMT
Subject: RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan
In-Reply-To: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
References: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
Message-ID: <6IQY8UFdUN_EsbdiDjbFXomPnXw-q5u0-6Rci-pTSMo=.19136ca5-169c-4fb1-b9f5-1f7e4829bf9e@github.com>

On Tue, 21 Feb 2023 16:40:07 GMT, Justin King <jcking at openjdk.org> wrote:

> Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots of warnings.

@magicus Trivial change for ASan under MSVC. Was giving it a run through tier1 today and noticed MSVC complaining heavily in build logs about `-DEBUG` not being passed. Adding it to `LDFLAGS` to shut it up, confirmed its quiet now.

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

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


From mikael at openjdk.org  Tue Feb 21 17:57:06 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 21 Feb 2023 17:57:06 GMT
Subject: RFR: 8303016: Invalid escapes in grep patterns
Message-ID: <t3X914GRfUxThZpvFw1XQcArjRpdMSkqm5A_O4b6PKg=.53ae4996-f4f0-405b-84c7-ae3067673229@github.com>

In a few grep patterns characters are escaped when they shouldn't be. Some grep versions seem to ignore this, but Cygwin grep generates a warning:

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

Commit messages:
 - Update copyright years
 - Remove unnecessary escape in grep patterns

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

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


From mikael at openjdk.org  Tue Feb 21 18:06:12 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 21 Feb 2023 18:06:12 GMT
Subject: RFR: 8303020: Remove carriage return in pandoc version string
Message-ID: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>

On windows/cygwin, the PANDOC_VERSION variable includes the carriage return ('\r') which makes the version check fail:

checking for pandoc version... 2.19.2
, not the recommended version 2.19.2n 2.19.2

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

Commit messages:
 - Fix pandoc version check on Windows

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

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


From iris at openjdk.org  Tue Feb 21 18:22:30 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 21 Feb 2023 18:22:30 GMT
Subject: RFR: 8303020: Remove carriage return in pandoc version string
In-Reply-To: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
References: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
Message-ID: <FV11sp6jmTF7DrwcRSClIG_eJNZ0wuv5aHDwlUoUyrA=.2e56678a-2aa0-462c-a5e2-932c7e3808ba@github.com>

On Tue, 21 Feb 2023 17:59:07 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> On windows/cygwin, the PANDOC_VERSION variable includes the carriage return ('\r') which makes the version check fail:
> 
> checking for pandoc version... 2.19.2
> , not the recommended version 2.19.2n 2.19.2

Marked as reviewed by iris (Reviewer).

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

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


From lancea at openjdk.org  Tue Feb 21 18:26:24 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 21 Feb 2023 18:26:24 GMT
Subject: RFR: 8303020: Remove carriage return in pandoc version string
In-Reply-To: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
References: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
Message-ID: <4BbeMZ0NAgI_9OStsXjwGzMt68YUJb46dgKEEcQSw4s=.8f0ce4ed-f269-4983-a0ea-899b48151e06@github.com>

On Tue, 21 Feb 2023 17:59:07 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> On windows/cygwin, the PANDOC_VERSION variable includes the carriage return ('\r') which makes the version check fail:
> 
> checking for pandoc version... 2.19.2
> , not the recommended version 2.19.2n 2.19.2

Marked as reviewed by lancea (Reviewer).

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

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


From naoto at openjdk.org  Tue Feb 21 19:46:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 21 Feb 2023 19:46:25 GMT
Subject: RFR: 8301119: Support for GB18030-2022
Message-ID: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>

Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

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

Commit messages:
 - Check initPhase and don't call System.getProperty if in phase 1
 - Some clean-up
 - Some more fixes
 - removed unnecessary method name composition
 - Removed unnecessary imports
 - aliases fix
 - Move GB18030 into standard charsets provider
 - indentation
 - Removed unused annotation
 - Removed null check
 - ... and 4 more: https://git.openjdk.org/jdk/compare/574b48c6...0f3c25ce

Changes: https://git.openjdk.org/jdk/pull/12518/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12518&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301119
  Stats: 283 lines in 14 files changed: 129 ins; 41 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

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


From erikj at openjdk.org  Tue Feb 21 20:21:23 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 21 Feb 2023 20:21:23 GMT
Subject: RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan
In-Reply-To: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
References: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
Message-ID: <kM5VblZex6xjFcbxd14XKnHtf56Pod4ak0FSrdZpk8o=.b657d362-8c42-43bb-a03a-b92ca0ff92e7@github.com>

On Tue, 21 Feb 2023 16:40:07 GMT, Justin King <jcking at openjdk.org> wrote:

> Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots of warnings.

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Tue Feb 21 20:22:25 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 21 Feb 2023 20:22:25 GMT
Subject: RFR: 8303020: Remove carriage return in pandoc version string
In-Reply-To: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
References: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
Message-ID: <Rec4pJex3VZZSMOeZtf3nt4iC8ftkdZnrvNvd78VnI8=.6b7ee972-7894-43c9-8491-caf67362fbb2@github.com>

On Tue, 21 Feb 2023 17:59:07 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> On windows/cygwin, the PANDOC_VERSION variable includes the carriage return ('\r') which makes the version check fail:
> 
> checking for pandoc version... 2.19.2
> , not the recommended version 2.19.2n 2.19.2

Marked as reviewed by erikj (Reviewer).

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

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


From erikj at openjdk.org  Tue Feb 21 20:22:27 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 21 Feb 2023 20:22:27 GMT
Subject: RFR: 8303016: Invalid escapes in grep patterns
In-Reply-To: <t3X914GRfUxThZpvFw1XQcArjRpdMSkqm5A_O4b6PKg=.53ae4996-f4f0-405b-84c7-ae3067673229@github.com>
References: <t3X914GRfUxThZpvFw1XQcArjRpdMSkqm5A_O4b6PKg=.53ae4996-f4f0-405b-84c7-ae3067673229@github.com>
Message-ID: <HKASykDV4EeflYVZerPmj7sT-orjL9wZ4mj5uO3gIHs=.c002825c-3ab6-4e30-ad39-d1e330cd3e1f@github.com>

On Tue, 21 Feb 2023 17:49:21 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> In a few grep patterns characters are escaped when they shouldn't be. Some grep versions seem to ignore this, but Cygwin grep generates a warning:

Marked as reviewed by erikj (Reviewer).

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

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


From mikael at openjdk.org  Tue Feb 21 21:04:02 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 21 Feb 2023 21:04:02 GMT
Subject: RFR: 8303020: Remove carriage return in pandoc version string
In-Reply-To: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
References: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
Message-ID: <WWKg0B3FIrorTcwOBHLNuWBoz1JmxpQMfkOndFy5kXA=.07d24ef2-216b-47c9-bfb4-c0f3dfa025c0@github.com>

On Tue, 21 Feb 2023 17:59:07 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> On windows/cygwin, the PANDOC_VERSION variable includes the carriage return ('\r') which makes the version check fail:
> 
> checking for pandoc version... 2.19.2
> , not the recommended version 2.19.2n 2.19.2

Thank you all!

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

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


From mikael at openjdk.org  Tue Feb 21 21:04:03 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 21 Feb 2023 21:04:03 GMT
Subject: Integrated: 8303020: Remove carriage return in pandoc version string
In-Reply-To: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
References: <l4cKOIdlf7Sqxf-PaSIkerzGqpr7VEjlA5NsC0SVnDw=.7e75ac57-2eb7-4601-80eb-cdc919982d80@github.com>
Message-ID: <jz7V0maZFjVqMgfK13EtiZcsCHCKqCzF8dQgqot77TY=.d1eedb2a-bcdf-4c38-b7df-1f23ea574af9@github.com>

On Tue, 21 Feb 2023 17:59:07 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> On windows/cygwin, the PANDOC_VERSION variable includes the carriage return ('\r') which makes the version check fail:
> 
> checking for pandoc version... 2.19.2
> , not the recommended version 2.19.2n 2.19.2

This pull request has now been integrated.

Changeset: 729c26f7
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/729c26f70ea89232ba7c0f2d8e4cb8116d6ca051
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8303020: Remove carriage return in pandoc version string

Reviewed-by: iris, lancea, erikj

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

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


From jcking at openjdk.org  Tue Feb 21 21:18:23 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 21 Feb 2023 21:18:23 GMT
Subject: RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan
In-Reply-To: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
References: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
Message-ID: <6I5ZIlzvWf2dSkYeE6vFQDeh1RA9O398yDQnozf7Nt4=.cf1ba45e-da04-4401-aaee-5d14398ba686@github.com>

On Tue, 21 Feb 2023 16:40:07 GMT, Justin King <jcking at openjdk.org> wrote:

> Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots of warnings.

Linux GHA tests look unrelated. This is MSVC-only change.

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

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


From jcking at openjdk.org  Tue Feb 21 21:18:23 2023
From: jcking at openjdk.org (Justin King)
Date: Tue, 21 Feb 2023 21:18:23 GMT
Subject: Integrated: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan
In-Reply-To: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
References: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
Message-ID: <Ke6kBsFUhOmjRGIRFDEup0CXtSMCswMpBSy0Pglj3zU=.33a76975-109a-4612-b3cf-7b95722301e3@github.com>

On Tue, 21 Feb 2023 16:40:07 GMT, Justin King <jcking at openjdk.org> wrote:

> Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots of warnings.

This pull request has now been integrated.

Changeset: ce6de371
Author:    Justin King <jcking at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce6de37172cadc3671c03423cb9dd3bb9d2be840
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8303010: Add /DEBUG to LDFLAGS for MSVC with ASan

Reviewed-by: erikj

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

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


From mikael at openjdk.org  Tue Feb 21 22:13:34 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 21 Feb 2023 22:13:34 GMT
Subject: RFR: 8303016: Invalid escapes in grep patterns
In-Reply-To: <t3X914GRfUxThZpvFw1XQcArjRpdMSkqm5A_O4b6PKg=.53ae4996-f4f0-405b-84c7-ae3067673229@github.com>
References: <t3X914GRfUxThZpvFw1XQcArjRpdMSkqm5A_O4b6PKg=.53ae4996-f4f0-405b-84c7-ae3067673229@github.com>
Message-ID: <1KdJeIiJ5pHfP4V12UbdKQUl3goY2uoeZmSryvQIgGc=.c04d6c73-1ba9-444b-976f-764cab67eb2b@github.com>

On Tue, 21 Feb 2023 17:49:21 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> In a few grep patterns characters are escaped when they shouldn't be. Some grep versions seem to ignore this, but Cygwin grep generates a warning:

Thank you!

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

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


From mikael at openjdk.org  Tue Feb 21 22:13:34 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Tue, 21 Feb 2023 22:13:34 GMT
Subject: Integrated: 8303016: Invalid escapes in grep patterns
In-Reply-To: <t3X914GRfUxThZpvFw1XQcArjRpdMSkqm5A_O4b6PKg=.53ae4996-f4f0-405b-84c7-ae3067673229@github.com>
References: <t3X914GRfUxThZpvFw1XQcArjRpdMSkqm5A_O4b6PKg=.53ae4996-f4f0-405b-84c7-ae3067673229@github.com>
Message-ID: <PtEak421W-UFjfFVX8DUOiIqJMFHiF_CjSZsvKuA2ro=.84860790-0312-41b4-a85f-af84ccb1877e@github.com>

On Tue, 21 Feb 2023 17:49:21 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> In a few grep patterns characters are escaped when they shouldn't be. Some grep versions seem to ignore this, but Cygwin grep generates a warning:

This pull request has now been integrated.

Changeset: f319c92b
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f319c92bd0fc68a64e6ac35ad4569740b858c9b2
Stats:     5 lines in 3 files changed: 0 ins; 0 del; 5 mod

8303016: Invalid escapes in grep patterns

Reviewed-by: erikj

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

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


From dholmes at openjdk.org  Wed Feb 22 00:32:38 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Feb 2023 00:32:38 GMT
Subject: RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan
In-Reply-To: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
References: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
Message-ID: <9ynQ03YDumkRi-2ikMzitg82063xDb3nfTfPYBlrYfI=.37451b01-43aa-4eda-8d0f-a96b1aaf926b@github.com>

On Tue, 21 Feb 2023 16:40:07 GMT, Justin King <jcking at openjdk.org> wrote:

> Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots of warnings.

If ASAN support needs `-debug` wouldn't it make sense to restrict its use to debug builds?

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

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


From jcking at openjdk.org  Wed Feb 22 00:36:47 2023
From: jcking at openjdk.org (Justin King)
Date: Wed, 22 Feb 2023 00:36:47 GMT
Subject: RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan
In-Reply-To: <9ynQ03YDumkRi-2ikMzitg82063xDb3nfTfPYBlrYfI=.37451b01-43aa-4eda-8d0f-a96b1aaf926b@github.com>
References: <duTkpTRMGa5nXGNSNryW4ELMTTt1uQaIS6XbkBxUmN8=.32441976-74ec-4225-8a6f-69de44227a09@github.com>
 <9ynQ03YDumkRi-2ikMzitg82063xDb3nfTfPYBlrYfI=.37451b01-43aa-4eda-8d0f-a96b1aaf926b@github.com>
Message-ID: <EjRX8qQ-CBYQi7DtRpfRdv3kt8MovwaTPw8e5FBj9F8=.46339025-8faa-4d19-a0f1-b3c4a43f01fb@github.com>

On Wed, 22 Feb 2023 00:29:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If ASAN support needs `-debug` wouldn't it make sense to restrict its use to debug builds?

MSVC named it poorly, IMO. It just means generate PDB basically.

It doesn't *need* it, just complains that stack traces are better with it.

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

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


From tanksherman27 at gmail.com  Wed Feb 22 07:11:45 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Wed, 22 Feb 2023 15:11:45 +0800
Subject: Windows compiled pandoc seems to not work properly
Message-ID: <CAP2b4GOT5KXbC8eE6EG09+zwSumpyDSgYYG25X5R6RMKJ1upwg@mail.gmail.com>

Hi all,

While generating docs on Windows, it appears to me that pandoc compiled
natively for the Windows OS itself never seems to work properly, and when
used completely mangles not only the entire html file of which the
corresponding markdown file was edited, but every single other html file
in the doc directory as well. Only downloading a Linux pandoc (following
the link in the pandoc bundle creator) and hopping onto WSL (MSYS2 cannot
run Linux executables) seems to work. I've not yet created a bug for this,
since I don't know whether this is a problem with our code or with
pandoc's. Has anyone else on a Windows device faced this issue as well?

best regards,
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230222/e68e8234/attachment.htm>

From alanb at openjdk.org  Wed Feb 22 10:00:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 10:00:31 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <78oXv8oehtNFwbwcPyczGNkWZcLFjxWH4pUDin1KTTI=.ca90d92f-04d2-47cc-8da9-e956f315046f@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 211:

> 209: 
> 210:     // Lazily initialized system property value
> 211:     private static String GB18030_2000;

I assume this should be a stable field.

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

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


From coffeys at openjdk.org  Wed Feb 22 10:48:55 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 22 Feb 2023 10:48:55 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 217:

> 215:             if (VM.initLevel() < 1) {
> 216:                 // Cannot get the system property yet. Assumes non-2000
> 217:                 GB18030_2000 = "";

curious - what scenario triggers this call at initLevel < 1 ? would it be better to simply return "false" at that time and leave the GB18030_2000 variable to be set once we're at initLevel >=1  ?  -- or perhaps that would invalidate the workflow of the original caller (which called in at initLevel <1)

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

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


From alanb at openjdk.org  Wed Feb 22 11:38:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 11:38:14 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
Message-ID: <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>

On Wed, 22 Feb 2023 10:46:10 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> curious - what scenario triggers this call at initLevel < 1 ?

It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.

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

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


From erik.joelsson at oracle.com  Wed Feb 22 13:52:42 2023
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Wed, 22 Feb 2023 05:52:42 -0800
Subject: Windows compiled pandoc seems to not work properly
In-Reply-To: <CAP2b4GOT5KXbC8eE6EG09+zwSumpyDSgYYG25X5R6RMKJ1upwg@mail.gmail.com>
References: <CAP2b4GOT5KXbC8eE6EG09+zwSumpyDSgYYG25X5R6RMKJ1upwg@mail.gmail.com>
Message-ID: <34cbc131-a6be-e847-c60c-40a67ae3af9b@oracle.com>

It's a known problem, though we could certainly handle it better.

https://bugs.openjdk.org/browse/JDK-8223157

/Erik

On 2/21/23 23:11, Julian Waters wrote:
> Hi all,
>
> While generating docs on Windows, it appears?to me?that pandoc 
> compiled natively for?the Windows OS itself never seems?to work 
> properly, and when used completely mangles not only?the entire html 
> file of which?the corresponding markdown file was edited, but every 
> single other html file in?the doc directory as well. Only downloading 
> a Linux pandoc (following the link in the pandoc bundle creator) and 
> hopping onto WSL (MSYS2 cannot run Linux executables) seems?to work. 
> I've not yet created a bug for?this, since I don't know whether?this 
> is a problem with our code or with pandoc's. Has anyone else on a 
> Windows device faced?this issue as well?
>
> best regards,
> Julian


From tanksherman27 at gmail.com  Wed Feb 22 14:00:26 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Wed, 22 Feb 2023 22:00:26 +0800
Subject: Windows compiled pandoc seems to not work properly
In-Reply-To: <34cbc131-a6be-e847-c60c-40a67ae3af9b@oracle.com>
References: <CAP2b4GOT5KXbC8eE6EG09+zwSumpyDSgYYG25X5R6RMKJ1upwg@mail.gmail.com>
 <34cbc131-a6be-e847-c60c-40a67ae3af9b@oracle.com>
Message-ID: <CAP2b4GNqFejuiori3RLk--gQFns66=QFdVABwuFF=3nT=-T8Eg@mail.gmail.com>

Hi Erik, thanks for the heads up, I'll look at the linked entry closer

~Julian

On Wed, Feb 22, 2023 at 9:52 PM <erik.joelsson at oracle.com> wrote:

> It's a known problem, though we could certainly handle it better.
>
> https://bugs.openjdk.org/browse/JDK-8223157
>
> /Erik
>
> On 2/21/23 23:11, Julian Waters wrote:
> > Hi all,
> >
> > While generating docs on Windows, it appears to me that pandoc
> > compiled natively for the Windows OS itself never seems to work
> > properly, and when used completely mangles not only the entire html
> > file of which the corresponding markdown file was edited, but every
> > single other html file in the doc directory as well. Only downloading
> > a Linux pandoc (following the link in the pandoc bundle creator) and
> > hopping onto WSL (MSYS2 cannot run Linux executables) seems to work.
> > I've not yet created a bug for this, since I don't know whether this
> > is a problem with our code or with pandoc's. Has anyone else on a
> > Windows device faced this issue as well?
> >
> > best regards,
> > Julian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230222/acb3739d/attachment.htm>

From alanb at openjdk.org  Wed Feb 22 15:22:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Feb 2023 15:22:04 GMT
Subject: RFR: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <TEAzveqaYCtriT9l0ikO71z2k7_mBhd5AD6s2t-YPyw=.253b065a-90f1-4f84-a7de-fdc71326d91d@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Overall I think it looks very good, just StandardCharsets.isGB18030_2000 needs attention. Having GB18030 be in java.base in all builds, rather than everywhere except macOS, is okay and makes things a lot simpler.

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

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


From duke at openjdk.org  Wed Feb 22 17:40:31 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Wed, 22 Feb 2023 17:40:31 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
Message-ID: <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>

> Improves performance and correctness, as discussed on the net-dev mailing list.

Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:

 - Forgot to add file
 - Resolve review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12593/files
  - new: https://git.openjdk.org/jdk/pull/12593/files/b23d139e..da66b503

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

  Stats: 263 lines in 5 files changed: 101 ins; 108 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/12593.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12593/head:pull/12593

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


From duke at openjdk.org  Wed Feb 22 17:40:34 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Wed, 22 Feb 2023 17:40:34 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v2]
In-Reply-To: <M2ZPlFDcazCXyxKYltg_KW7q8ZAkLkXyREZBg4A373c=.a5f4ddaf-3a19-4f96-a38f-21643e3f4086@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <M2ZPlFDcazCXyxKYltg_KW7q8ZAkLkXyREZBg4A373c=.a5f4ddaf-3a19-4f96-a38f-21643e3f4086@github.com>
Message-ID: <Mbn8MD88W5JRaktnblHEHWt3XkunlU__utWt1uq68JY=.b699279e-9463-40b0-a264-d9e80add387f@github.com>

On Fri, 17 Feb 2023 10:37:30 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Rich DiCroce has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Limit line length to 80-ish characters
>
> I don't think the NetworkInterface.h file should be dropped.
> It is preferrable that typedef and struct decalarations remain in a header file rather than being merged into .c file.

@msheppar I've moved the struct declaration back to the .h file.

The full jdk_net suite passes on my machine.

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

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


From duke at openjdk.org  Wed Feb 22 17:40:42 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Wed, 22 Feb 2023 17:40:42 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
Message-ID: <7LpCtjmCPqQ8Jh-uW4i_75c-DY38GmEEyPQzIeeTx9I=.2a9fad99-8dc1-4f06-aff2-58d1aa676cb0@github.com>

On Thu, 16 Feb 2023 15:48:17 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Forgot to add file
>>  - Resolve review comments
>
> src/java.base/windows/native/libnet/NetworkInterface.c line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2003, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2000, 2023, Oracle and/or its affiliates. All rights reserved.

Fixed.

> src/java.base/windows/native/libnet/NetworkInterface.c line 62:
> 
>> 60: typedef struct _netaddr {
>> 61:     SOCKADDR_INET Address;
>> 62:     SCOPE_ID ScopeId;
> 
> Not used

Removed. Good catch.

> src/java.base/windows/native/libnet/NetworkInterface.c line 67:
> 
>> 65: } netaddr;
>> 66: 
>> 67: BOOL getAddressTables(MIB_UNICASTIPADDRESS_TABLE **uniAddrs, MIB_ANYCASTIPADDRESS_TABLE **anyAddrs) {
> 
> Please mark all functions that are local to this file as `static`, this will help the compiler

Done.

> src/java.base/windows/native/libnet/NetworkInterface.c line 69:
> 
>> 67: BOOL getAddressTables(MIB_UNICASTIPADDRESS_TABLE **uniAddrs, MIB_ANYCASTIPADDRESS_TABLE **anyAddrs) {
>> 68:     ADDRESS_FAMILY addrFamily = ipv6_available() ? AF_UNSPEC : AF_INET;
>> 69:     if (GetUnicastIpAddressTable(addrFamily, uniAddrs) != NO_ERROR) {
> 
> Please add error handling to all WinAPI calls; something like:
> 
> NET_ThrowByNameWithLastError(env, JNU_JAVANETPKG "SocketException", "GetUnicastIpAddressTable");
> 
> You may also need to use `SetLastError(ret)` before calling NET_Throw...; the WinAPI functions are not documented to do it, and we do not have a function that would take the error code as a parameter.

Done.

> src/java.base/windows/native/libnet/NetworkInterface.c line 393:
> 
>> 391:  * Signature: ()[Ljava/net/NetworkInterface;
>> 392:  */
>> 393: JNIEXPORT jobjectArray JNICALL Java_java_net_NetworkInterface_getAll(JNIEnv *env, jclass cls) {
> 
> This may have also fixed [JDK-6798979](https://bugs.openjdk.org/browse/JDK-6798979) and [JDK-8165665](https://bugs.openjdk.org/browse/JDK-8165665) (which is a good thing!)

I agree, it looks like both of those would be fixed by these changes.

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

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


From duke at openjdk.org  Wed Feb 22 17:40:43 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Wed, 22 Feb 2023 17:40:43 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <DzCziVgHpcWFLUzE6OqCVlKsgnwhPhR29nbc78NUO74=.168a43ee-da3f-4ab8-85bf-d39926b74875@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
 <YrqcagiZH-PmknZqRyWNS0odIVn4mynZYVuLX6-WnHM=.908a9ca0-ec91-4160-8cb9-59af153f0ac9@github.com>
 <DzCziVgHpcWFLUzE6OqCVlKsgnwhPhR29nbc78NUO74=.168a43ee-da3f-4ab8-85bf-d39926b74875@github.com>
Message-ID: <jeXTj74XydDZbTO-rBxzwo5CKa8BAEmX9_3wCryF8l4=.dbea652f-c00b-48b7-8db1-88a93d2829bc@github.com>

On Fri, 17 Feb 2023 20:58:13 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> For the IPv6 code, this should be the same as before. See getAddrsFromAdapter in the original code, which enumerates the unicast addresses first and then does the anycast addresses.
>> 
>> For IPv4, I'm not sure. The MS docs for GetIpAddrTable don't say, and I don't have any systems where I could determine it experimentally.
>
> I tried creating an anycast address using the [CreateAnycastIpAddressEntry API](https://learn.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-createanycastipaddressentry) and the [New-NetIPAddress Powershell command](https://learn.microsoft.com/en-us/powershell/module/nettcpip/new-netipaddress?view=windowsserver2022-ps), but I only managed to lock myself out from a VM; creating the address failed with ERROR_NOT_SUPPORTED, and the powershell command additionally disabled DHCP on the selected interface.
> 
> With that in mind I'm fine with the code in its current form. We may revisit the issue if and when someone figures out how to add an anycast address.

Okay, I don't have any way to test it either, so leaving it as-is.

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

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


From duke at openjdk.org  Wed Feb 22 17:40:44 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Wed, 22 Feb 2023 17:40:44 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <iajubMV_C7bgMEIojOXyzuKnkrYM2erec1btol-I2VU=.6d253f15-0163-471b-80f9-525c62de384c@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <7HMNE7he3xeseFZyzK49F5n_YZL2DcLARZtOwpdnk6U=.64977be5-bf55-4e1e-a85e-0fb9b8598e61@github.com>
 <A0rFhnO7A9qtOv3EER4UIVbRwSDgqKvoqZevQreKF9Y=.0053afb0-7cb4-42a4-adbf-ff151e7a3977@github.com>
 <njL-lKEZ7z886PvCv4sULPOpdI0iwe-yAlsaEmTNvgY=.5ffd751e-8b8e-4dbc-9cc4-49135cfdd14c@github.com>
 <1en36lUgplk03paOtfrxk-Aoiop5Toe2Sd7oVcx74K4=.ef33f250-b03a-44d8-adcc-1e3dff6b55dc@github.com>
 <ZTK_RPj42NlKZXGbE7jpBLr5CLG-u3byte3KM1fU1-A=.e2d89b9b-f524-4aff-b330-d46c95d6894c@github.com>
 <KXOgOmZJcNXej2bqOW8i8jffiOXgtMi42tuZ4U1Jgkw=.3f05fe94-8a9c-463d-820c-7e46ea92c56c@github.com>
 <uLpe7n8lEcuqTgXi1oh3csHwAdKuV5WvwPYsBB252O4=.97ef5c2f-6ddc-468b-969f-e7bdf8168a0b@github.com>
 <ZtaW6W021evEqiZFkOBv956WjgTAIPlUSk6hb9RNryY=.7cd9c1a3-6566-4fbb-974e-745444807a64@github.com>
 <iajubMV_C7bgMEIojOXyzuKnkrYM2erec1btol-I2VU=.6d253f15-0163-471b-80f9-525c62de384c@github.com>
Message-ID: <wj1M27UiThybeJ0qI6OWw1N9Z2vu-_laazJz4GsrEwU=.1f3b87ae-df8f-49e2-a751-4b9a16d770d2@github.com>

On Fri, 17 Feb 2023 20:51:35 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Though it's more complicated than that. Some machines may have both IPv6 and IPv4, some machine may only have IPv4, and some machine may only have IPv6. I haven't looked at the test yet, but picking up the right interface on the various platforms has always been an issue for our tests.
>
> So,, apparently this is a Windows feature. [Older socket implementation](https://github.com/openjdk/jdk11/blob/37115c8ea4aff13a8148ee2b8832b20888a5d880/src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c#L1350) had an explicit check for addresses bound to an interface, and only interfaces with associated addresses could be used for multicasting.
> 
> This needs to be fixed in the test. Can you add a check for addresses to `OptionsTest.getNetworkInterface`?
> 
> Beyond that, I'm fine with an implementation that unconditionally returns `true`.

I've adjusted OptionsTest as @djelinski suggested, and changed the implementation to always return true. I left the giant comment so that when future devs wonder WTF we were thinking, they'll have the answer.

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

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


From naoto at openjdk.org  Wed Feb 22 18:22:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 18:22:33 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <zjw9cgUgI3rGDV9gW7xcpCuSpDeBi10TK7AZoSjP970=.81f3937a-b471-4bf7-8bc5-ebaf0c9f0ae7@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato 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 16 additional commits since the last revision:

 - Add @Stable annotation
 - Merge branch 'master' into JDK-8301119-GB18030-2022
 - Check initPhase and don't call System.getProperty if in phase 1
 - Some clean-up
 - Some more fixes
 - removed unnecessary method name composition
 - Removed unnecessary imports
 - aliases fix
 - Move GB18030 into standard charsets provider
 - indentation
 - ... and 6 more: https://git.openjdk.org/jdk/compare/0981ec17...b5379b69

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/0f3c25ce..b5379b69

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

  Stats: 8209 lines in 333 files changed: 4912 ins; 1488 del; 1809 mod
  Patch: https://git.openjdk.org/jdk/pull/12518.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12518/head:pull/12518

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


From naoto at openjdk.org  Wed Feb 22 18:22:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Feb 2023 18:22:41 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
Message-ID: <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>

On Wed, 22 Feb 2023 11:34:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template line 217:
>> 
>>> 215:             if (VM.initLevel() < 1) {
>>> 216:                 // Cannot get the system property yet. Assumes non-2000
>>> 217:                 GB18030_2000 = "";
>> 
>> curious - what scenario triggers this call at initLevel < 1 ? would it be better to simply return "false" at that time and leave the GB18030_2000 variable to be set once we're at initLevel >=1  ?  -- or perhaps that would invalidate the workflow of the original caller (which called in at initLevel <1)
>
>> curious - what scenario triggers this call at initLevel < 1 ?
> 
> It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.

`Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.

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

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


From redestad at openjdk.org  Thu Feb 23 08:35:04 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 08:35:04 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
Message-ID: <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>

On Wed, 22 Feb 2023 17:52:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> curious - what scenario triggers this call at initLevel < 1 ?
>> 
>> It's not supported, but it is possible that someone might run with -Dfile.encoding=GB18030, in which case the default charset is used before the system properties are initialized in initPhase1. Checking the init level breaks the circularity, the only downside is that can't switch to GB18030-2000 at the same time.
>
> `Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.

`@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.

I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.

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

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


From redestad at openjdk.org  Thu Feb 23 08:58:02 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 23 Feb 2023 08:58:02 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
Message-ID: <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>

On Thu, 23 Feb 2023 08:32:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `Charset` class is initialized *before* system properties are set up, in order to check the JNU encoding (used for file path name) is a supported charset or not. In some OS environments, GB18030 is the native encoding so we need to avoid checking the system property in such a case.
>
> `@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.
> 
> I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.

Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:


    isGB18030_2000() { return GB18030Properties.GB18030_2000; }

    private static class GB18030Properties {
        private static final GB18030_2000 = init();
        private static boolean init() {
            if (VM.initLevel() < 1) {
                // Cannot get the system property yet. Assumes non-2000
                return false;
            }
            return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
        }
    }

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

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


From alanb at openjdk.org  Thu Feb 23 09:07:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 09:07:10 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
Message-ID: <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>

On Thu, 23 Feb 2023 08:55:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> `@Stable` semantics are still fuzzy to me but the rule I've adhered to is that back to back stores to the field - if unavoidable - needs to be idempotent since the JIT (or AOT) may record any non-null value as a compile time constant at any time.
>> 
>> I'd write this to not update the static field if initLevel() < 1. Such calls should be rare and only happen once on a system that has GB18030 as their native encoding.
>
> Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:
> 
> 
>     isGB18030_2000() { return GB18030Properties.GB18030_2000; }
> 
>     private static class GB18030Properties {
>         private static final GB18030_2000 = init();
>         private static boolean init() {
>             if (VM.initLevel() < 1) {
>                 // Cannot get the system property yet. Assumes non-2000
>                 return false;
>             }
>             return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
>         }
>     }

Right, doing nothing for the initLevel < 1 case means that  `-Dfile.encoding=GB18030 -Djdk.charset.GB18030=2000` would use version 2022 in early startup (JNU encoding init) and then switch to version 2000. Using a holder class seems a better idea than trying to coordinate concurrent writers.

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

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


From coffeys at openjdk.org  Thu Feb 23 09:51:06 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 23 Feb 2023 09:51:06 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
Message-ID: <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>

On Thu, 23 Feb 2023 09:03:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Scratch that: as it seems to be important that we don't switch after startup then what this code is really reaching for is `static final` field semantics. Since `StandardCharsets` might be loaded very early a holder class pattern might be necessary:
>> 
>> 
>>     isGB18030_2000() { return GB18030Properties.GB18030_2000; }
>> 
>>     private static class GB18030Properties {
>>         private static final GB18030_2000 = init();
>>         private static boolean init() {
>>             if (VM.initLevel() < 1) {
>>                 // Cannot get the system property yet. Assumes non-2000
>>                 return false;
>>             }
>>             return "2000".equals(GetPropertyAction.privilegedGetProperty("jdk.charset.GB18030"));
>>         }
>>     }
>
> Right, doing nothing for the initLevel < 1 case means that  `-Dfile.encoding=GB18030 -Djdk.charset.GB18030=2000` would use version 2022 in early startup (JNU encoding init) and then switch to version 2000. Using a holder class seems a better idea than trying to coordinate concurrent writers.

would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?

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

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


From alanb at openjdk.org  Thu Feb 23 10:10:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Feb 2023 10:10:08 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v2]
In-Reply-To: <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
 <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
Message-ID: <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>

On Thu, 23 Feb 2023 09:48:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?

The early startup scenario is early in the system property initialization, specifically SystemProps.Raw.<clinit> which will cause the encoding to be initialized. This has to avoid make use of system properties, otherwise you get a circular initialization issue.

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

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


From djelinski at openjdk.org  Thu Feb 23 12:20:16 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Feb 2023 12:20:16 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
Message-ID: <P01YWhFhvZPukRJvS3SDobbhNm1lxeP5um3tkJYFbXI=.adc4688d-0608-4c71-9ba2-5c43d9b67105@github.com>

On Wed, 22 Feb 2023 17:40:31 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to add file
>  - Resolve review comments

make/modules/java.base/Lib.gmk line 50:

> 48:     DISABLED_WARNINGS_clang_net_util_md.c := format-nonliteral, \
> 49:     DISABLED_WARNINGS_microsoft_InetAddress.c := 4244, \
> 50:     DISABLED_WARNINGS_microsoft_NetworkInterface.c := 4133, \

This line is no longer necessary

src/java.base/windows/native/libnet/NetworkInterface.c line 110:

> 108:     // set the NetworkInterface's name
> 109:     apiRetVal = ConvertInterfaceLuidToNameW(
> 110:             &(ifRow->InterfaceLuid), (PWSTR) &ifName, NDIS_IF_MAX_BUFFER_SIZE);

Suggestion:

            &(ifRow->InterfaceLuid), ifName, NDIS_IF_MAX_BUFFER_SIZE);

src/java.base/windows/native/libnet/NetworkInterface.c line 118:

> 116:     }
> 117:     name = (*env)->NewString(
> 118:             env, (const jchar *) &ifName, (jsize) wcslen((const wchar_t *) &ifName));

Suggestion:

            env, ifName, (jsize) wcslen(ifName));

src/java.base/windows/native/libnet/NetworkInterface.c line 128:

> 126:     displayName = (*env)->NewString(
> 127:             env, (const jchar *) ifRow->Description,
> 128:             (jsize) wcslen((const wchar_t *) &(ifRow->Description)));

Suggestion:

            env, ifRow->Description,
            (jsize) wcslen(ifRow->Description));

src/java.base/windows/native/libnet/NetworkInterface.c line 295:

> 293:     apiRetVal = GetIfEntry2(ifRow);
> 294:     if (apiRetVal != NO_ERROR) {
> 295:         if (throwIfNotFound && apiRetVal == ERROR_FILE_NOT_FOUND) {

Suggestion:

        if (throwIfNotFound || apiRetVal != ERROR_FILE_NOT_FOUND) {

src/java.base/windows/native/libnet/NetworkInterface.c line 334:

> 332: 
> 333:     ifRow.InterfaceIndex = index;
> 334:     return createNetworkInterfaceForSingleRow(env, FALSE, &ifRow);

once you fix the `throwIfNotFound` issue above, you'll also need special handling for index 0 here; `GetIfEntry2` will return ERROR_INVALID_PARAMETER when index is zero (zero means not set)

src/java.base/windows/native/libnet/NetworkInterface.c line 360:

> 358:         return NULL;
> 359:     }
> 360:     return createNetworkInterfaceForSingleRow(env, TRUE, &ifRow);

Suggestion:

    return createNetworkInterfaceForSingleRow(env, FALSE, &ifRow);

`ConvertInterfaceNameToLuidW` does not verify interface existence; without this change `NetworkInterface.getByName("loopback_1")` would throw instead of returning null

src/java.base/windows/native/libnet/NetworkInterface.c line 387:

> 385:             ifRow.InterfaceLuid = uniAddrs->Table[i].InterfaceLuid;
> 386:             result = createNetworkInterfaceForSingleRowWithTables(
> 387:                     env, TRUE, &ifRow, uniAddrs, anyAddrs);

Suggestion:

                    env, FALSE, &ifRow, uniAddrs, anyAddrs);

network interfaces are notoriously disappearing at the least convenient time

src/java.base/windows/native/libnet/NetworkInterface.c line 396:

> 394:             ifRow.InterfaceLuid = anyAddrs->Table[i].InterfaceLuid;
> 395:             result = createNetworkInterfaceForSingleRowWithTables(
> 396:                     env, TRUE, &ifRow, uniAddrs, anyAddrs);

Suggestion:

                    env, FALSE, &ifRow, uniAddrs, anyAddrs);

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

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


From djelinski at openjdk.org  Thu Feb 23 12:47:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Feb 2023 12:47:10 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
Message-ID: <hGKApPnfXzJvrZ4YIKl4IWPAu_G9Dl3Xhx8ACnFIT-k=.101ca2f5-4dcd-4248-8e69-7e31662db740@github.com>

On Wed, 22 Feb 2023 17:40:31 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to add file
>  - Resolve review comments

I searched for other WinAPIs of interest; [GetIfStackTable](https://learn.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-getifstacktable) caught my attention.
As far as I could see, the network interfaces are arranged in a stack with many filter interfaces stacked on top of a single non-filter interface. All interfaces in a stack return the same values from `isUp`, `isPointToPoint`, `isLoopback` and `getHardwareAddress`. The filter interfaces do not have any IP addresses, and are not usable with multicast sockets.
I'm not sure how we could put that information to use. Ideas welcome.

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

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


From dfuchs at openjdk.org  Thu Feb 23 14:45:08 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 23 Feb 2023 14:45:08 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <hGKApPnfXzJvrZ4YIKl4IWPAu_G9Dl3Xhx8ACnFIT-k=.101ca2f5-4dcd-4248-8e69-7e31662db740@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
 <hGKApPnfXzJvrZ4YIKl4IWPAu_G9Dl3Xhx8ACnFIT-k=.101ca2f5-4dcd-4248-8e69-7e31662db740@github.com>
Message-ID: <N8CIGucRFfPrWNS3mmOoQmJRgT8vrZovO_DTjLGdqpI=.32d74eab-b726-4c24-8c6e-7cd55dc5edec@github.com>

On Thu, 23 Feb 2023 12:44:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> I searched for other WinAPIs of interest; [GetIfStackTable](https://learn.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-getifstacktable) caught my attention.
> As far as I could see, the network interfaces are arranged in a stack with many filter interfaces stacked on top of a single non-filter interface. All interfaces in a stack return the same values from `isUp`, `isPointToPoint`, `isLoopback` and `getHardwareAddress`. The filter interfaces do not have any IP addresses, and are not usable with multicast sockets.
> I'm not sure how we could put that information to use. Ideas welcome.

Is there anything practical a Java Application could do with these interfaces? Except displaying them for debugging purposes? I mean - for instance - would it work if you tried, or are there case where it would be necessary,  to set one of these as the outgoing interface of a multicast socket?
Otherwise maybe we could just filter the filters out for now...

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

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


From duke at openjdk.org  Thu Feb 23 15:21:11 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Thu, 23 Feb 2023 15:21:11 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <N8CIGucRFfPrWNS3mmOoQmJRgT8vrZovO_DTjLGdqpI=.32d74eab-b726-4c24-8c6e-7cd55dc5edec@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
 <hGKApPnfXzJvrZ4YIKl4IWPAu_G9Dl3Xhx8ACnFIT-k=.101ca2f5-4dcd-4248-8e69-7e31662db740@github.com>
 <N8CIGucRFfPrWNS3mmOoQmJRgT8vrZovO_DTjLGdqpI=.32d74eab-b726-4c24-8c6e-7cd55dc5edec@github.com>
Message-ID: <m2qce3ou3f_hSIfT-U2hh-8oAKHmCNc81IZSQn5htkI=.83f23a7d-99ff-47c9-8df9-118980675552@github.com>

On Thu, 23 Feb 2023 14:42:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > I searched for other WinAPIs of interest; [GetIfStackTable](https://learn.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-getifstacktable) caught my attention.
> > As far as I could see, the network interfaces are arranged in a stack with many filter interfaces stacked on top of a single non-filter interface. All interfaces in a stack return the same values from `isUp`, `isPointToPoint`, `isLoopback` and `getHardwareAddress`. The filter interfaces do not have any IP addresses, and are not usable with multicast sockets.
> > I'm not sure how we could put that information to use. Ideas welcome.
> 
> Is there anything practical a Java Application could do with these interfaces? Except displaying them for debugging purposes? I mean - for instance - would it work if you tried, or are there case where it would be necessary, to set one of these as the outgoing interface of a multicast socket? Otherwise maybe we could just filter the filters out for now...

I'm not sure if there's anything useful a Java application could do with the filter interfaces. I can't think of any. Having said that, the filter interfaces are returned by the existing code, so if we stop returning them, that is a functional change. I'm okay with that if you guys are.

But note that it is not guaranteed that all filters on top of an interface would return the same values for e.g. `isUp()`. The docs for [GetIfTable2Ex](https://learn.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-getiftable2ex) provide an example of this:

> An NDIS filter driver (LWF) can be attached on top of the NDIS intermediate driver. Assume that the NIC reports the MediaConnectState member of the MIB_IF_ROW2 structure as MediaConnectStateConnected but NDIS filter driver modifies the state and reports the state as MediaConnectStateDisconnected. When the interface information is queried with Level parameter set to MibIfTableNormal, the state at the top of the filter stack, that is MediaConnectStateDisconnected is reported. When the interface is queried with the Level parameter set to MibIfTableRaw, the state at the interface level directly, that is MediaConnectStateConnected is returned.

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

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


From jwaters at openjdk.org  Thu Feb 23 19:25:53 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 23 Feb 2023 19:25:53 GMT
Subject: RFR: 8303131: pandoc.exe mangles all processed html files
Message-ID: <VLuLqkMAXvG9XbLZRccBjmukhX1CzbMvFCQ6fNLHQD4=.8aee4d01-8905-4c0b-989f-0eb9e7ad1f31@github.com>

pandoc.exe follows the Windows CRLF format of newlines, whereas we only ever have LF in our documentation files. As a result whenever we generate html the resulting html files will all be mangled, even if there was no change to the corresponding markdown file. This passes --eol=lf to pandoc so that it always uses LF no matter the platform, since we never ever seem to use (or even want to use) CRLF at all, so that pandoc will exhibit consistent behaviour on all platforms

pandoc by default uses the --eol=native option, which is LF on macOS, Linux and UNIX, so this change will not affect their html generation whatsoever, but will make the lives of Windows JDK developers and _especially_ JDK developers working with MSYS2 a hell of a lot easier (*cries internally)

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

Commit messages:
 - ProcessMarkdown.gmk

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

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


From naoto at openjdk.org  Thu Feb 23 19:34:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 19:34:44 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Moved the 2000 flag into GB18030

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/b5379b69..4d4015a9

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

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

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


From naoto at openjdk.org  Thu Feb 23 19:36:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Feb 2023 19:36:10 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <S6p8hZiWOrDpXAzaeJ3L4kOIferQtFHKmFaa_1gNTyo=.0a245135-1bf9-47a1-b992-36edcbc2d612@github.com>
 <Fo1WnNOBMptjHkVUUtdvx4p03Ci1ljacM9bkFux2Qus=.b8082d30-35e9-491e-88a0-d00105f4381b@github.com>
 <C8Fp0qE368HZbCo1tQIMBh44wZ19PyfQFcKlKWKcYnc=.1bbcec03-19ad-4f98-aff5-669ab82f2c0a@github.com>
 <yG5N8VCa7i5JK8uFGZ4am4f5YfkKNPRLn5f5eYox51A=.123fd849-517e-444d-b479-984bc39888de@github.com>
 <wO2OP3VuH8E8OF6GSkl0a-c6b6Sy1np5d2ThZO1sj1A=.4bb265be-df50-46cc-9976-2334f6f1e9ba@github.com>
 <jpkQafw1j_0fH0-cumhhoGpqMqfqFXCG-4lHUckF66I=.6e01f41d-7854-4c5a-be59-0eb5e4a78a49@github.com>
 <ljBTRKBiP-miZ-LTBn4BKKgWtuB-EB8woNMy74YaN68=.4ebd8a62-371d-4dc1-a441-08fa03913f4f@github.com>
 <DZeiL86cxzx9DTJMKK5mvr8ywYt0TTP5V2ex3BkWjKM=.13f06b0c-f341-4b53-9f47-d275135d369f@github.com>
Message-ID: <B4IvJCeiXPoSRP0Zr5eaSdK6GzcoWoZ6jjytYs80yxw=.546521a6-49b5-4aaf-8b3a-09ddc25aa5d3@github.com>

On Thu, 23 Feb 2023 10:07:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?
>
>> would use of jdk.internal.util.SystemProps be an option here (if having to retrieve that value when we're at VM init level <1 ?
> 
> The early startup scenario is early in the system property initialization, specifically SystemProps.Raw.<clinit> which will cause the encoding to be initialized. This has to avoid make use of system properties, otherwise you get a circular initialization issue.

> what this code is really reaching for is `static final` field semantics.

Exactly. Introducing the holder pattern in `StandardCharset` would solve the issue, but instead I moved the flag init into `GB18030` so that we can literally make it `static final`.

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

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


From erikj at openjdk.org  Thu Feb 23 21:05:05 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 23 Feb 2023 21:05:05 GMT
Subject: RFR: 8303131: pandoc.exe mangles all processed html files
In-Reply-To: <VLuLqkMAXvG9XbLZRccBjmukhX1CzbMvFCQ6fNLHQD4=.8aee4d01-8905-4c0b-989f-0eb9e7ad1f31@github.com>
References: <VLuLqkMAXvG9XbLZRccBjmukhX1CzbMvFCQ6fNLHQD4=.8aee4d01-8905-4c0b-989f-0eb9e7ad1f31@github.com>
Message-ID: <f4r3X7zJ8u6IkO_e7RVw2bJ32EuUcGREtQN3GWJRvos=.b09a6049-19f2-442f-bc1f-38112b19eac7@github.com>

On Thu, 23 Feb 2023 19:18:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> pandoc.exe follows the Windows CRLF format of newlines, whereas we only ever have LF in our documentation files. As a result whenever we generate html the resulting html files will all be mangled, even if there was no change to the corresponding markdown file. This passes --eol=lf to pandoc so that it always uses LF no matter the platform, since we never ever seem to use (or even want to use) CRLF at all, so that pandoc will exhibit consistent behaviour on all platforms
> 
> pandoc by default uses the --eol=native option, which is LF on macOS, Linux and UNIX, so this change will not affect their html generation whatsoever, but will make the lives of Windows JDK developers and _especially_ JDK developers working with MSYS2 a hell of a lot easier (*cries internally)

Marked as reviewed by erikj (Reviewer).

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

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


From alanb at openjdk.org  Fri Feb 24 07:56:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 07:56:10 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <sZ6e3IQf74n8JeZ3jS2RCtNXc3rZVNEhssWPZBF3Syc=.689d0581-f8b8-4d4a-8cbc-bc47868801ba@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Latest version looks good to me, avoids needing stable field or holder class.

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

Marked as reviewed by alanb (Reviewer).

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


From itakiguchi at openjdk.org  Fri Feb 24 08:38:07 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 24 Feb 2023 08:38:07 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Hello @naotoj .
Sorry for bothering you.

I have following question:
- Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
Is there specific reason ?

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

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


From jwaters at openjdk.org  Fri Feb 24 08:52:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 24 Feb 2023 08:52:18 GMT
Subject: RFR: 8303131: pandoc.exe mangles all processed html files
In-Reply-To: <f4r3X7zJ8u6IkO_e7RVw2bJ32EuUcGREtQN3GWJRvos=.b09a6049-19f2-442f-bc1f-38112b19eac7@github.com>
References: <VLuLqkMAXvG9XbLZRccBjmukhX1CzbMvFCQ6fNLHQD4=.8aee4d01-8905-4c0b-989f-0eb9e7ad1f31@github.com>
 <f4r3X7zJ8u6IkO_e7RVw2bJ32EuUcGREtQN3GWJRvos=.b09a6049-19f2-442f-bc1f-38112b19eac7@github.com>
Message-ID: <89Sfzo3p-rF8WbylOIYgctom8txw6OOimMpu6bux_5M=.f466a3df-c808-411b-8eb0-ee96dce24e95@github.com>

On Thu, 23 Feb 2023 21:01:52 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> pandoc.exe follows the Windows CRLF format of newlines, whereas we only ever have LF in our documentation files. As a result whenever we generate html the resulting html files will all be mangled, even if there was no change to the corresponding markdown file. This passes --eol=lf to pandoc so that it always uses LF no matter the platform, since we never ever seem to use (or even want to use) CRLF at all, so that pandoc will exhibit consistent behaviour on all platforms
>> 
>> pandoc by default uses the --eol=native option, which is LF on macOS, Linux and UNIX, so this change will not affect their html generation whatsoever, but will make the lives of Windows JDK developers and _especially_ JDK developers working with MSYS2 a hell of a lot easier (*cries internally)
>
> Marked as reviewed by erikj (Reviewer).

Thanks for the review @erikj79!

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

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


From jwaters at openjdk.org  Fri Feb 24 08:52:20 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 24 Feb 2023 08:52:20 GMT
Subject: Integrated: 8303131: pandoc.exe mangles all processed html files
In-Reply-To: <VLuLqkMAXvG9XbLZRccBjmukhX1CzbMvFCQ6fNLHQD4=.8aee4d01-8905-4c0b-989f-0eb9e7ad1f31@github.com>
References: <VLuLqkMAXvG9XbLZRccBjmukhX1CzbMvFCQ6fNLHQD4=.8aee4d01-8905-4c0b-989f-0eb9e7ad1f31@github.com>
Message-ID: <YMRle2eDOGbHgv3gs_MnO1VfuPfs1sszeE5YUf3GiLs=.05f59c57-b499-481d-b1fa-e804aa30af20@github.com>

On Thu, 23 Feb 2023 19:18:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> pandoc.exe follows the Windows CRLF format of newlines, whereas we only ever have LF in our documentation files. As a result whenever we generate html the resulting html files will all be mangled, even if there was no change to the corresponding markdown file. This passes --eol=lf to pandoc so that it always uses LF no matter the platform, since we never ever seem to use (or even want to use) CRLF at all, so that pandoc will exhibit consistent behaviour on all platforms
> 
> pandoc by default uses the --eol=native option, which is LF on macOS, Linux and UNIX, so this change will not affect their html generation whatsoever, but will make the lives of Windows JDK developers and _especially_ JDK developers working with MSYS2 a hell of a lot easier (*cries internally)

This pull request has now been integrated.

Changeset: 7d8b8ba9
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d8b8ba9c46475ededcae7db6c841b25fa83d167
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8303131: pandoc.exe mangles all processed html files

Reviewed-by: erikj

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

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


From coffeys at openjdk.org  Fri Feb 24 11:01:08 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 24 Feb 2023 11:01:08 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
Message-ID: <gheAf1iB5AFGkfIwBYGfJdW6VvlIc-OGjuCdRQAoyEw=.7f6710eb-8e4a-4376-816a-f16cd1cc8cef@github.com>

On Thu, 23 Feb 2023 19:34:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved the 2000 flag into GB18030

Marked as reviewed by coffeys (Reviewer).

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

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


From alanb at openjdk.org  Fri Feb 24 11:40:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Feb 2023 11:40:05 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
Message-ID: <A2XsV6jvLtc5K_RfoEb1yWVRiSu_TJpgpe0Syc4joek=.a2e0741f-6595-4d05-85b8-00ead2e70cc0@github.com>

On Fri, 24 Feb 2023 08:34:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?

That is a good question. It could move, and $PACKAGE replaced with sun.nio.cs, so it would be more obvious from the source location that it is generated into java.base rather than jdk.charsets. Up until now, GB18030 went into java.base on some platforms and jdk.charsets on other platforms. It will be the same for all platforms once this PR is integrated.

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

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


From jcking at openjdk.org  Fri Feb 24 15:45:51 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Feb 2023 15:45:51 GMT
Subject: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC
Message-ID: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>

Disable RTTI `-GR-` for Hotspot when building with MSVC. This drops the size of `jvm.dll` by roughly 1 MB. Hotspot does not rely on RTTI and it is disabled for both GCC/Clang and Open XL C/C++ already. This change disables it for MSVC, ensuring we do not accidently rely on RTTI for Windows-specific code while also decreasing the resulting binary size.

Cheers to @alexmenkov for finding the tricky root cause of why disabling RTTI was causing a subset of serviceability agent tests to fail.

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

Commit messages:
 - Force MSVC to emit unique vtable for NotificationThread
 - Disable RTTI with MSVC

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

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


From naoto at openjdk.org  Fri Feb 24 17:23:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 17:23:25 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v4]
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Failed to add the file itself
 - Changed GB18030 from extcs template to stdcs source

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12518/files
  - new: https://git.openjdk.org/jdk/pull/12518/files/4d4015a9..9732e6c8

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

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

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


From naoto at openjdk.org  Fri Feb 24 17:23:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 24 Feb 2023 17:23:26 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
Message-ID: <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>

On Fri, 24 Feb 2023 08:34:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> Hello @naotoj . Sorry for bothering you.
> 
> I have following question:
> 
> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>   I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>   Is there specific reason ?

No, there is not. Thanks for pointing it out. Fixed.

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

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


From lancea at openjdk.org  Fri Feb 24 18:14:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Feb 2023 18:14:09 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v4]
In-Reply-To: <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <-1jawaJzkA_7STPSnbSTZ6O6CgZi4UJa70D-UlkzgGE=.3386f1b5-ab83-4cad-89fa-9313fa3cbf8f@github.com>
Message-ID: <NCWMZuJeSCZIJ64fwTHe2VgNC01TtAaxVGeRj8fh-x4=.8249b760-5221-4dfe-96bc-30672a3934c2@github.com>

On Fri, 24 Feb 2023 17:23:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Failed to add the file itself
>  - Changed GB18030 from extcs template to stdcs source

Marked as reviewed by lancea (Reviewer).

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

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


From cjplummer at openjdk.org  Fri Feb 24 19:44:06 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Feb 2023 19:44:06 GMT
Subject: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC
In-Reply-To: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
References: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
Message-ID: <dkGjyngKD2iyEogZL9AUMTysRPrgEEU9nBBmPpgiCC0=.ce8b94f4-5812-455b-8fe9-69050e626676@github.com>

On Fri, 24 Feb 2023 15:36:16 GMT, Justin King <jcking at openjdk.org> wrote:

> Disable RTTI `-GR-` for Hotspot when building with MSVC. This drops the size of `jvm.dll` by roughly 1 MB. Hotspot does not rely on RTTI and it is disabled for both GCC/Clang and Open XL C/C++ already. This change disables it for MSVC, ensuring we do not accidently rely on RTTI for Windows-specific code while also decreasing the resulting binary size.
> 
> Cheers to @alexmenkov for finding the tricky root cause of why disabling RTTI was causing a subset of serviceability agent tests to fail.

src/hotspot/share/runtime/notificationThread.hpp line 48:

> 46:   // we do not override any virtual methods and RTTI is disabled, MSVC may emit a single vtable for
> 47:   // JavaThread and NotificationThread. This results in the vtable symbols for both classes pointing
> 48:   // to the same address and Serviceability Agent thinking all JavaThread are NotificationThread. So

Suggestion:

  // to the same address, and Serviceability Agent thinking all JavaThreads are NotificationThreads. So

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

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


From jcking at openjdk.org  Fri Feb 24 19:52:41 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Feb 2023 19:52:41 GMT
Subject: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC
 [v2]
In-Reply-To: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
References: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
Message-ID: <DtVJPb3ZoC8QmHMWf3pDCr-w1oaCb3dd9Qy-UQ_8DrA=.05e6baeb-97b8-44b2-a2ec-9e0cce39078c@github.com>

> Disable RTTI `-GR-` for Hotspot when building with MSVC. This drops the size of `jvm.dll` by roughly 1 MB. Hotspot does not rely on RTTI and it is disabled for both GCC/Clang and Open XL C/C++ already. This change disables it for MSVC, ensuring we do not accidently rely on RTTI for Windows-specific code while also decreasing the resulting binary size.
> 
> Cheers to @alexmenkov for finding the tricky root cause of why disabling RTTI was causing a subset of serviceability agent tests to fail.

Justin King has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/notificationThread.hpp
  
  Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12743/files
  - new: https://git.openjdk.org/jdk/pull/12743/files/87d707eb..9a882207

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

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

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


From jcking at openjdk.org  Fri Feb 24 19:56:39 2023
From: jcking at openjdk.org (Justin King)
Date: Fri, 24 Feb 2023 19:56:39 GMT
Subject: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC
 [v3]
In-Reply-To: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
References: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
Message-ID: <HDsN6dQyAGBeoyUgtNQKjX3ru4v23K-uI6LCdr_VcsY=.311e554e-0d91-492c-abe2-5a0af356c468@github.com>

> Disable RTTI `-GR-` for Hotspot when building with MSVC. This drops the size of `jvm.dll` by roughly 1 MB. Hotspot does not rely on RTTI and it is disabled for both GCC/Clang and Open XL C/C++ already. This change disables it for MSVC, ensuring we do not accidently rely on RTTI for Windows-specific code while also decreasing the resulting binary size.
> 
> Cheers to @alexmenkov for finding the tricky root cause of why disabling RTTI was causing a subset of serviceability agent tests to fail.

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

 - Merge remote-tracking branch 'upstream/master' into msvc-rtti
 - Update src/hotspot/share/runtime/notificationThread.hpp
   
   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
 - Force MSVC to emit unique vtable for NotificationThread
   
   Signed-off-by: Justin King <jcking at google.com>
 - Disable RTTI with MSVC
   
   Signed-off-by: Justin King <jcking at google.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12743/files
  - new: https://git.openjdk.org/jdk/pull/12743/files/9a882207..42932cdd

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

  Stats: 4490 lines in 198 files changed: 3104 ins; 751 del; 635 mod
  Patch: https://git.openjdk.org/jdk/pull/12743.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12743/head:pull/12743

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


From amenkov at openjdk.org  Sat Feb 25 01:51:03 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 25 Feb 2023 01:51:03 GMT
Subject: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC
 [v3]
In-Reply-To: <HDsN6dQyAGBeoyUgtNQKjX3ru4v23K-uI6LCdr_VcsY=.311e554e-0d91-492c-abe2-5a0af356c468@github.com>
References: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
 <HDsN6dQyAGBeoyUgtNQKjX3ru4v23K-uI6LCdr_VcsY=.311e554e-0d91-492c-abe2-5a0af356c468@github.com>
Message-ID: <HiLNeNWJrGlbIs3CO2zSbRCxHnDao0Ggr0lJeKQEJZo=.d40a6eac-9cd7-432d-9de7-70f320ffef9e@github.com>

On Fri, 24 Feb 2023 19:56:39 GMT, Justin King <jcking at openjdk.org> wrote:

>> Disable RTTI `-GR-` for Hotspot when building with MSVC. This drops the size of `jvm.dll` by roughly 1 MB. Hotspot does not rely on RTTI and it is disabled for both GCC/Clang and Open XL C/C++ already. This change disables it for MSVC, ensuring we do not accidently rely on RTTI for Windows-specific code while also decreasing the resulting binary size.
>> 
>> Cheers to @alexmenkov for finding the tricky root cause of why disabling RTTI was causing a subset of serviceability agent tests to fail.
>
> Justin King has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into msvc-rtti
>  - Update src/hotspot/share/runtime/notificationThread.hpp
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - Force MSVC to emit unique vtable for NotificationThread
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Disable RTTI with MSVC
>    
>    Signed-off-by: Justin King <jcking at google.com>

Need to update copyright year in flags-cflags.m4 and notificationThread.hpp

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

Marked as reviewed by amenkov (Reviewer).

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


From kbarrett at openjdk.org  Sat Feb 25 11:08:04 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 25 Feb 2023 11:08:04 GMT
Subject: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC
 [v3]
In-Reply-To: <HDsN6dQyAGBeoyUgtNQKjX3ru4v23K-uI6LCdr_VcsY=.311e554e-0d91-492c-abe2-5a0af356c468@github.com>
References: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
 <HDsN6dQyAGBeoyUgtNQKjX3ru4v23K-uI6LCdr_VcsY=.311e554e-0d91-492c-abe2-5a0af356c468@github.com>
Message-ID: <e0LcUWjloQ8gFYHRRL062NG-F1GxkhWS7-DvM3gUGM4=.314f071a-d8f8-43bf-9144-e2f17cc3253c@github.com>

On Fri, 24 Feb 2023 19:56:39 GMT, Justin King <jcking at openjdk.org> wrote:

>> Disable RTTI `-GR-` for Hotspot when building with MSVC. This drops the size of `jvm.dll` by roughly 1 MB. Hotspot does not rely on RTTI and it is disabled for both GCC/Clang and Open XL C/C++ already. This change disables it for MSVC, ensuring we do not accidently rely on RTTI for Windows-specific code while also decreasing the resulting binary size.
>> 
>> Cheers to @alexmenkov for finding the tricky root cause of why disabling RTTI was causing a subset of serviceability agent tests to fail.
>
> Justin King has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into msvc-rtti
>  - Update src/hotspot/share/runtime/notificationThread.hpp
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - Force MSVC to emit unique vtable for NotificationThread
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Disable RTTI with MSVC
>    
>    Signed-off-by: Justin King <jcking at google.com>

src/hotspot/share/runtime/notificationThread.hpp line 50:

> 48:   // to the same address, and Serviceability Agent thinking all JavaThreads are NotificationThreads. So
> 49:   // while this method is not directly used anywhere, it must exist.
> 50:   bool is_Notification_thread() const override { return true; }

Rather than adding this method, would it be sufficient to explicitly define `~NotificationThread()`?
Might require making it non-trivial.  The comment would still be needed.

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

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


From itakiguchi at openjdk.org  Sun Feb 26 04:39:17 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sun, 26 Feb 2023 04:39:17 GMT
Subject: RFR: 8301119: Support for GB18030-2022 [v3]
In-Reply-To: <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
 <DbcSeT1d1ulLxFGuScNUYOimyD_bbHn9miPe9TvlSH8=.a10fd674-22b4-4d6b-ac97-3772babbcd3d@github.com>
 <U-4zjhKODj0JRTHSx_FChBEHLABanbxFBr9nmvg8Vks=.f25ff406-6bcc-4376-ac89-609ae5affd32@github.com>
 <ItbPT4G9FTT2V3dUBPOY6PGOQmidBqQYrfvoWW29JgY=.2cbc927a-04ab-47ee-a5bb-3c6e488190c3@github.com>
Message-ID: <7dEDXuB8aO0XFkF9AaUZwP9chbjr5RFzvz1mYZnIx4g=.5ef6ecc2-829e-4c97-a662-4a51768ab994@github.com>

On Fri, 24 Feb 2023 17:19:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> Sorry for bothering you.
>> 
>> I have following question:
>> - Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>> I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>> Is there specific reason ?
>
>> Hello @naotoj . Sorry for bothering you.
>> 
>> I have following question:
>> 
>> * Why GB18030.java.template is in src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory even if the generated code is always stored into sun/nio/cs ?
>>   I think the file should be moved to src/java.base/share/classes/sun/nio/cs and the file name should be GB18030.java instead of GB18030.java.template.
>>   Is there specific reason ?
> 
> No, there is not. Thanks for pointing it out. Fixed.

Thanks @naotoj .
That's what I expected.

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

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


From dholmes at openjdk.org  Sun Feb 26 06:13:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 26 Feb 2023 06:13:05 GMT
Subject: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC
 [v3]
In-Reply-To: <HDsN6dQyAGBeoyUgtNQKjX3ru4v23K-uI6LCdr_VcsY=.311e554e-0d91-492c-abe2-5a0af356c468@github.com>
References: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
 <HDsN6dQyAGBeoyUgtNQKjX3ru4v23K-uI6LCdr_VcsY=.311e554e-0d91-492c-abe2-5a0af356c468@github.com>
Message-ID: <HbwUiGf8X-tdGKqTujWf5VB8XNP6JEarSiywq03QtRk=.b74a145b-8eaa-4b4b-b7ec-0b856e0b5508@github.com>

On Fri, 24 Feb 2023 19:56:39 GMT, Justin King <jcking at openjdk.org> wrote:

>> Disable RTTI `-GR-` for Hotspot when building with MSVC. This drops the size of `jvm.dll` by roughly 1 MB. Hotspot does not rely on RTTI and it is disabled for both GCC/Clang and Open XL C/C++ already. This change disables it for MSVC, ensuring we do not accidently rely on RTTI for Windows-specific code while also decreasing the resulting binary size.
>> 
>> Cheers to @alexmenkov for finding the tricky root cause of why disabling RTTI was causing a subset of serviceability agent tests to fail.
>
> Justin King has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into msvc-rtti
>  - Update src/hotspot/share/runtime/notificationThread.hpp
>    
>    Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>  - Force MSVC to emit unique vtable for NotificationThread
>    
>    Signed-off-by: Justin King <jcking at google.com>
>  - Disable RTTI with MSVC
>    
>    Signed-off-by: Justin King <jcking at google.com>

The workaround should have been done under JDK-8302817. This issue should have simply disabled RTTI in the build system.

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

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


From jcking at openjdk.org  Sun Feb 26 18:06:14 2023
From: jcking at openjdk.org (Justin King)
Date: Sun, 26 Feb 2023 18:06:14 GMT
Subject: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC
 [v3]
In-Reply-To: <HbwUiGf8X-tdGKqTujWf5VB8XNP6JEarSiywq03QtRk=.b74a145b-8eaa-4b4b-b7ec-0b856e0b5508@github.com>
References: <GA6YeGTsHMl7v4B88CvzDbWQlLGzkQHGRDgEC6RUVpw=.3dff253d-6162-44a9-bb65-2346b74c7bab@github.com>
 <HDsN6dQyAGBeoyUgtNQKjX3ru4v23K-uI6LCdr_VcsY=.311e554e-0d91-492c-abe2-5a0af356c468@github.com>
 <HbwUiGf8X-tdGKqTujWf5VB8XNP6JEarSiywq03QtRk=.b74a145b-8eaa-4b4b-b7ec-0b856e0b5508@github.com>
Message-ID: <JYu4J_FlF2d2mFncJKxtWWs6Jp7lMZsOQayObtDGl78=.ada6094d-eb34-4f06-992d-aee64b3e1bdf@github.com>

On Sun, 26 Feb 2023 06:10:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The workaround should have been done under JDK-8302817. This issue should have simply disabled RTTI in the build system.

I'll split the RTTI disable to a separate PR Monday, leave this one as the workaround, and rename to the other issue.

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

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


From asotona at openjdk.org  Mon Feb 27 09:17:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 09:17:51 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <9Q436PkBJ4HIYF1ZSYJz_gEL3A1qfpjZKWKc82NVD6k=.7ce49423-395b-430a-9aa5-111106b77937@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
 <1G9rLfYBxfxcwmzgd7VDXnTfrW252lIui-9sWVAAhn0=.d3e5b0e6-66cc-4322-ae31-282954e9d3ca@github.com>
 <9Q436PkBJ4HIYF1ZSYJz_gEL3A1qfpjZKWKc82NVD6k=.7ce49423-395b-430a-9aa5-111106b77937@github.com>
Message-ID: <bp6VPURfS3ajLjC2RugoLD3qc8T389XZfHcJp63Xghw=.d5593950-b799-4cb4-a7b4-9a1fd69f85fa@github.com>

On Fri, 17 Feb 2023 17:09:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes, the print structure does not exactly correspond to the Classfile API architecture, but rather to the classfile physical structure and it is partly similar to `javap` output.
>> The common tree structure has been reverse-designed from the desired visual representations in all supported text formats and in all verbosity levels.
>
> Not sure I get this. It seems to me that the same attributes are being printed twice. But, perhaps, the first pass only creates a list with the attribute _names_ and then there is a later pass which print the attributes in full?

Yes, the first is just a list of attribute names, while later there might be printed more attribute details (depending on the verbosity).
Combined or dynamically changed list formats would be inconsistent in various verbosity levels, so duplicate print is preferred for better human and machine readability and consistency. 
There are other cases of duplication in favour of readability. For example some code attributes are printed standalone in a table form, as well as their individual elements are attached to the corresponding bytecode instructions.

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

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


From asotona at openjdk.org  Mon Feb 27 10:38:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 10:38:34 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <EJeQw3PZ5LrbxmlpIogsokswWXQcKsWfgIHmb1qoF20=.52246fe5-2e92-4fa4-af8a-5b3225cd0027@github.com>

On Thu, 16 Feb 2023 10:51:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 105:
> 
>> 103:          * @param out consumer of the printed fragments
>> 104:          */
>> 105:         default public void toJson(Consumer<String> out) {
> 
> there are some `public` modifiers here which can be omitted

will fix it, thanks.

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

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


From asotona at openjdk.org  Mon Feb 27 10:45:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 10:45:51 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <heurkAucA7r8KoKLty2Xe4PyaGuLbYy4rJJ8EeUyUAM=.29a64072-1322-4042-8010-cff4d0f986ae@github.com>

On Thu, 16 Feb 2023 10:54:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/ClassPrinter.java line 140:
> 
>> 138: 
>> 139:     /**
>> 140:      * A tree node holding {@link List} of nested nodes.
> 
> It would perhaps be beneficial to have little examples of what these different nodes are used for. I had to look at `ClassPrinterImpl` to get some idea.

I'll link examples from package-info here.

> src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 745:
> 
>> 743:                     list("stack", "item", Stream.of())));
>> 744:             }
>> 745:             var excHandlers = com.exceptionHandlers().stream().map(exc -> new ExceptionHandler(com.labelToBci(exc.tryStart()), com.labelToBci(exc.tryEnd()), com.labelToBci(exc.handler()), exc.catchType().map(ct -> ct.name().stringValue()).orElse(null))).toList();
> 
> Watch out for very long lines

wil fix it, thanks.

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

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


From asotona at openjdk.org  Mon Feb 27 11:51:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 11:51:26 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v24]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <4v-ieGzWVxROeQxyax-xle4OLw7bVqwG3S1EG7NlyR4=.9e3e3d41-ce7a-456c-91c5-cfd11bca3523@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - added no-lambda comment
 - fixed very long lines
 - removed obsolete public modifiers and added doc examples

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/1bf62016..9f465f1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=22-23

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

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


From asotona at openjdk.org  Mon Feb 27 11:58:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 11:58:05 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <uK2Mntlhl-bj6sd4xoVv-OD_Ap4H5uJWhginLxGQvKQ=.67f31945-ddff-414f-a953-4b27619db1c2@github.com>

On Thu, 16 Feb 2023 11:09:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 93:
> 
>> 91: 
>> 92: /**
>> 93:  * ClassRemapper is a {@link jdk.internal.classfile.ClassTransform}, {@link jdk.internal.classfile.FieldTransform},
> 
> Maybe wrap occurrences of `ClassRemapper` with `{@code}` (here and elsewhere)

will fix it, thanks.

> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 168:
> 
>> 166:         public void accept(ClassBuilder clb, ClassElement cle) {
>> 167:             switch (cle) {
>> 168:                 case FieldModel fm ->
> 
> What about NestMembers, NestHost, PermittedSubclasses (and probably others) ?

Right, ClassRemapper is incomplete, will work on it.

> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 306:
> 
>> 304: 
>> 305:         ClassSignature mapClassSignature(ClassSignature signature) {
>> 306:             return ClassSignature.of(signature.typeParameters(),
> 
> Should type parameters also be mapped? (as they might have class bounds). Both here and in `mapMethodSignature`.

Nice catch, will fix it, thanks!

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

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


From jdv at openjdk.org  Mon Feb 27 11:59:29 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 27 Feb 2023 11:59:29 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5 only on
 linux-aarch64
Message-ID: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>

Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.

Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.

We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.

With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.

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

Commit messages:
 - 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5 only on linux-aarch64

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

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


From asotona at openjdk.org  Mon Feb 27 13:15:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:15:40 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v25]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <z78UQ1fIJ3-fx_YT3M0eYZ84iKTkkoNtQ4rOBsneGCM=.b78b7070-4a82-4cd4-8c68-0be7bd983f48@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassRemapper fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/9f465f1a..dfb0e00e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=23-24

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

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


From asotona at openjdk.org  Mon Feb 27 13:15:44 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:15:44 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <uK2Mntlhl-bj6sd4xoVv-OD_Ap4H5uJWhginLxGQvKQ=.67f31945-ddff-414f-a953-4b27619db1c2@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
 <uK2Mntlhl-bj6sd4xoVv-OD_Ap4H5uJWhginLxGQvKQ=.67f31945-ddff-414f-a953-4b27619db1c2@github.com>
Message-ID: <PRYiMCCFXATzbAXyFu3FekcW6JUvAAA11RqOikgSGac=.25b957c4-5835-4a38-baa6-3a9b44424a57@github.com>

On Mon, 27 Feb 2023 11:54:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 168:
>> 
>>> 166:         public void accept(ClassBuilder clb, ClassElement cle) {
>>> 167:             switch (cle) {
>>> 168:                 case FieldModel fm ->
>> 
>> What about NestMembers, NestHost, PermittedSubclasses (and probably others) ?
>
> Right, ClassRemapper is incomplete, will work on it.

fixed

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

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Mon Feb 27 13:20:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:20:47 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v26]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <RE5D8dgfSeXSzov-yO1XC8X7FQPtgwl8kxZvMfaM4Nc=.ea788d4e-e5cf-440e-bd38-da6d695967f6@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/classfile/components/CodeRelabeler.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/dfb0e00e..7cbd080f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=24-25

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Mon Feb 27 13:38:37 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:38:37 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v27]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <DslcDrsYtIBJD4EO9QHYxONOXqUhJPKc-ovLIsOYXVU=.11c3cf3e-90be-48af-9fc9-ebf78963ea38@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  javadoc fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/7cbd080f..7002d719

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=25-26

  Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Mon Feb 27 13:38:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:38:42 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
Message-ID: <Hfba433pWvjDCL3CLuknu03Me1b3Zt4jnhOv--NFsoQ=.31db5bd0-a1ec-4b6b-97a9-361e91d91ac5@github.com>

On Thu, 16 Feb 2023 11:21:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/components/CodeLocalsShifter.java line 43:
> 
>> 41: 
>> 42: /**
>> 43:  * CodeLocalsShifter is a {@link jdk.internal.classfile.CodeTransform} shifting locals to
> 
> Missing `{@code}` (here and elsewhere)

fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 53:
> 
>> 51:  *         trackedBuilder.aload(0);
>> 52:  *         trackedBuilder.lconst_0();
>> 53:  *         trackedBuilder.ifThen(...
> 
> missing closed parens?

fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Mon Feb 27 13:38:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 27 Feb 2023 13:38:45 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <oYaLdiYyDVuK_MQipb_p3HpgH_p6xBZByVeG33jPYps=.2282798d-f696-4139-88a5-bbf0f3274ac5@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <Qn0tRwNM_VFrkCYp8klyMMUJRCUoB0muZ9E-UkUK8R4=.12a8c8b2-48cc-4ffe-b11e-0180c60bd4bf@github.com>
 <oYaLdiYyDVuK_MQipb_p3HpgH_p6xBZByVeG33jPYps=.2282798d-f696-4139-88a5-bbf0f3274ac5@github.com>
Message-ID: <B7FKcVbhFFy0jLPHiOoFz7LMUYVOAoOYN7BzyNsI6NM=.daa3734e-433f-40c5-bd19-7f4c5c4b39d0@github.com>

On Thu, 16 Feb 2023 11:29:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/components/CodeStackTracker.java line 43:
>> 
>>> 41: 
>>> 42: /**
>>> 43:  * CodeStackTracker is a {@link jdk.internal.classfile.CodeTransform} synchronously tracking
>> 
>> Not sure what is meant by `synchronously`
>
> Might want to use `{@code}` (here and elsewhere)

fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From duke at openjdk.org  Mon Feb 27 13:41:51 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Mon, 27 Feb 2023 13:41:51 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
Message-ID: <nMV4ixhSMIjf905OntaACb-ezLNGXX9TLtqnYMsucK0=.b349e447-2270-48e0-a557-f97ddf0be315@github.com>

On Wed, 22 Feb 2023 17:40:31 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to add file
>  - Resolve review comments

So, what's the verdict here? Do we keep the filter interfaces or get rid of them? If nobody has a strong opinion in favor of getting rid of them, I'm going to leave them alone, since filtering them out adds more complexity.

-------------

PR: https://git.openjdk.org/jdk/pull/12593


From jwaters at openjdk.org  Mon Feb 27 14:54:32 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 27 Feb 2023 14:54:32 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v31]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <etP4sC7FxnqF7J5kbRZPRznGvE-uadUm6mCrIeflW1A=.7b802150-28bf-4e54-822e-0cab2a67942a@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Register classpath and cproject

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/5745a0df..0d3dfb9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=29-30

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From erikj at openjdk.org  Mon Feb 27 15:17:06 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 27 Feb 2023 15:17:06 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64
In-Reply-To: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
Message-ID: <hCFzL1w5PE8nC5rLLmhVyKpJ92Hn9C3je0Rkzm8G_LI=.e5988211-03ab-4700-b25c-3c74d90c22a4@github.com>

On Mon, 27 Feb 2023 11:49:27 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
> 
> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
> 
> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
> 
> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 132:

> 130:   # that any cleanup of code related to AWT will not change the
> 131:   # generated code and cause performance issues in J2DBench
> 132:   LIBAWT_CFLAGS += -fpic

We compile with `-fPIC` as a standard flag for position independent code (I just verified that LIBAWT also gets this flag today). My understanding is that `-fpic` may result in smaller/faster code. Overriding with `-fpic` seems like its helping here, but the comment needs to be fixed to explain the actual difference and reason.

-------------

PR: https://git.openjdk.org/jdk/pull/12761


From alanb at openjdk.org  Mon Feb 27 15:29:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Feb 2023 15:29:28 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
Message-ID: <B0AqhBzYdCs6Uqg7me_2Jhk1a8lscd-gCUwScYVNjnI=.cae0b8e1-5113-4c01-b6f9-22e11595dbdd@github.com>

On Wed, 22 Feb 2023 17:40:31 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to add file
>  - Resolve review comments

src/java.base/windows/native/libnet/NetworkInterface.c line 288:

> 286: }
> 287: 
> 288: static jobject createNetworkInterfaceForSingleRowWithTables(

I think it would be helpful for future maintainers if there was a comment on each of static functions to make it clear what they do.

src/java.base/windows/native/libnet/NetworkInterface.h line 39:

> 37:     struct _netaddr *Next;
> 38: } netaddr;
> 39: 

Can NetworkInterface.h be dropped, and netaddr moved to NetworkInterface.c?

-------------

PR: https://git.openjdk.org/jdk/pull/12593


From duke at openjdk.org  Mon Feb 27 15:35:33 2023
From: duke at openjdk.org (Rich DiCroce)
Date: Mon, 27 Feb 2023 15:35:33 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <B0AqhBzYdCs6Uqg7me_2Jhk1a8lscd-gCUwScYVNjnI=.cae0b8e1-5113-4c01-b6f9-22e11595dbdd@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
 <B0AqhBzYdCs6Uqg7me_2Jhk1a8lscd-gCUwScYVNjnI=.cae0b8e1-5113-4c01-b6f9-22e11595dbdd@github.com>
Message-ID: <hXmpMV4IDczexG0h_I7h9V2NIFXc2lrMXXvPdDERIrI=.c822d5b7-4654-45b8-b50a-5c62f5157b47@github.com>

On Mon, 27 Feb 2023 15:25:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Forgot to add file
>>  - Resolve review comments
>
> src/java.base/windows/native/libnet/NetworkInterface.h line 39:
> 
>> 37:     struct _netaddr *Next;
>> 38: } netaddr;
>> 39: 
> 
> Can NetworkInterface.h be dropped, and netaddr moved to NetworkInterface.c?

I did that in an earlier revision. Then @msheppar asked for it to be moved back. See https://github.com/openjdk/jdk/pull/12593#issuecomment-1434450339

-------------

PR: https://git.openjdk.org/jdk/pull/12593


From dmarkov at openjdk.org  Mon Feb 27 16:03:50 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Mon, 27 Feb 2023 16:03:50 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
Message-ID: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>

Added the section devoted to client UI test which use Robot API

-------------

Commit messages:
 - 8303130: Document required Accessibility permissions on macOS

Changes: https://git.openjdk.org/jdk/pull/12772/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303130
  Stats: 52 lines in 2 files changed: 46 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12772.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12772/head:pull/12772

PR: https://git.openjdk.org/jdk/pull/12772


From jdv at openjdk.org  Mon Feb 27 16:16:50 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 27 Feb 2023 16:16:50 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
Message-ID: <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>

> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
> 
> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
> 
> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
> 
> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Update comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12761/files
  - new: https://git.openjdk.org/jdk/pull/12761/files/0c39e4c3..e8d25674

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12761/head:pull/12761

PR: https://git.openjdk.org/jdk/pull/12761


From jdv at openjdk.org  Mon Feb 27 16:16:55 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 27 Feb 2023 16:16:55 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <hCFzL1w5PE8nC5rLLmhVyKpJ92Hn9C3je0Rkzm8G_LI=.e5988211-03ab-4700-b25c-3c74d90c22a4@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <hCFzL1w5PE8nC5rLLmhVyKpJ92Hn9C3je0Rkzm8G_LI=.e5988211-03ab-4700-b25c-3c74d90c22a4@github.com>
Message-ID: <BXAvZyOtkMGqSiENteUtrqW8U6ME33weqLBMv_yPp-g=.fe68e96c-7968-4b57-bd12-f792a3e7d936@github.com>

On Mon, 27 Feb 2023 15:14:22 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 132:
> 
>> 130:   # that any cleanup of code related to AWT will not change the
>> 131:   # generated code and cause performance issues in J2DBench
>> 132:   LIBAWT_CFLAGS += -fpic
> 
> We compile with `-fPIC` as a standard flag for position independent code (I just verified that LIBAWT also gets this flag today). My understanding is that `-fpic` may result in smaller/faster code. Overriding with `-fpic` seems like its helping here, but the comment needs to be fixed to explain the actual difference and reason.

Thanks @erikj79 for your inputs. I have updated the comment to be relevant to the problem it is resolving.

-------------

PR: https://git.openjdk.org/jdk/pull/12761


From naoto at openjdk.org  Mon Feb 27 16:39:25 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Feb 2023 16:39:25 GMT
Subject: Integrated: 8301119: Support for GB18030-2022
In-Reply-To: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
References: <FXBchbCnbNloQO7Nlh9Ijue_c_YugGk-UC7_-ZAjY2o=.7e1ca01f-8cee-40bb-bb06-6e5670abe661@github.com>
Message-ID: <qgQlYhYos9HSO_KWfSk8FPX1pxdfch9VwquZcrsxiSc=.f6660687-b56d-464c-9e7b-5c349df3b46e@github.com>

On Fri, 10 Feb 2023 20:35:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the GB18030 charset in the JDK to the latest 2022 standard. Since this is not a compatible upgrade to the existing mapping, a new system property `jdk.charset.GB18030` is introduced. If it is set to "2000", the mapping falls back to the existing mapping based on the 2000 standard, otherwise, it defaults to 2022 mapping. Refer to the corresponding CSR for more detail.

This pull request has now been integrated.

Changeset: a253b460
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a253b4602147633a3d2e83775d1feef4f12a5272
Stats:     273 lines in 14 files changed: 117 ins; 41 del; 115 mod

8301119: Support for GB18030-2022

Reviewed-by: alanb, coffeys, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/12518


From chen.j.patrick at gmail.com  Mon Feb 27 16:39:48 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Mon, 27 Feb 2023 17:39:48 +0100
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
Message-ID: <CANmuJ8uwnH0weSvbLuEVq-PXUbjxsdSQFH=4DWRdjcLyjh3eEQ@mail.gmail.com>

lgtm


Le lun. 27 f?vr. 2023 ? 17:17, Jayathirth D V <jdv at openjdk.org> a ?crit :

> > Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level
> of gcc optimizations from -O1 level for libawt build. This improved our
> J2DBench performance numbers in some options considerably.
> >
> > Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337
> causes difference in generated code by gcc and this is resulting in
> performance regression for bimg_misc-* J2DBench options in our performance
> servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just
> removed unused variables and it is a cleanup task.
> >
> > We can force gcc to generate position independent code by using -fpic
> option.Also i have removed -fgcse-after-reload option for gcc, because this
> is by default covered under -O3 level of optimization introduced under
> https://bugs.openjdk.org/browse/JDK-8264846.
> >
> > With this change bimg_misc-* J2DBench option performance regression is
> resolved and there are no regression in other options of J2DBench or
> SwingMark and it is verified in our performance servers.
>
> Jayathirth D V has updated the pull request incrementally with one
> additional commit since the last revision:
>
>   Update comment
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.org/jdk/pull/12761/files
>   - new: https://git.openjdk.org/jdk/pull/12761/files/0c39e4c3..e8d25674
>
> Webrevs:
>  - full: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=01
>  - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=00-01
>
>   Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
>   Patch: https://git.openjdk.org/jdk/pull/12761.diff
>   Fetch: git fetch https://git.openjdk.org/jdk pull/12761/head:pull/12761
>
> PR: https://git.openjdk.org/jdk/pull/12761
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230227/fba7b1f4/attachment.htm>

From erikj at openjdk.org  Mon Feb 27 17:58:09 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 27 Feb 2023 17:58:09 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
Message-ID: <_yVCLOV6_nTrJK-y-oxkx5ul2Lz4cg0hh9nZsNhuBNM=.1a444733-2710-4ff4-a609-808a60fc0247@github.com>

On Mon, 27 Feb 2023 16:16:50 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
>> 
>> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
>> 
>> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
>> 
>> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12761


From aivanov at openjdk.org  Mon Feb 27 18:52:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 18:52:38 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <QZ4iENrRYXUbzM0yYnUaF1kZMxwkysqRQWklkD17t44=.6c5bc8e4-da8a-44e9-bf37-358ff8b5d631@github.com>

On Mon, 27 Feb 2023 15:54:28 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Added the section devoted to client UI test which use Robot API

doc/testing.md line 616:

> 614: system key shortcuts for various platforms are provided below.
> 615: 
> 616: ##### MacOS

Suggestion:

##### macOS

Shall we spell _macOS_ with lower-case ?m? like Apple does?

doc/testing.md line 648:

> 646: the default operating system settings need to be adjusted for correct work of
> 647: Robot functionality. The detailed steps how to access and update that settings
> 648: for different platforms are provided below.

Suggestion:

Most automated Client UI tests use `Robot` API to control the UI. Usually,
the default operating system settings need to be adjusted for Robot
to work correctly. The detailed steps how to access and update these settings
for different platforms are provided below.

doc/testing.md line 656:

> 654: Privacy & Security; select Accessibility and ensure the following apps are
> 655: allowed to control your computer: `Java` and `Terminal`. If the tests are run
> 656: from an IDE, the IDE should be granted this permission too.

Suggestion:

`Robot` is not permitted to control your Mac by default since
macOS 10.15. To enable it, choose Apple menu > System Settings, click
Privacy & Security, then click Accessibility and ensure the following apps are
allowed to control your computer: *Java* and *Terminal*. If the tests are run
from an IDE, the IDE should be granted this permission too.

I amended the instructions align with [Allow accessibility apps to access your Mac](https://support.apple.com/en-gb/guide/mac-help/mh43185/mac).

Perhaps, ?to allow it? is better than ?to enable it?. Also unsure about ?`Robot` is not *allowed* to control?? instead of ?permitted?.

*Java* and *Terminal* are the names of apps, not part of a command-line, therefore they're shouldn't be rendered in monospace font; using italics suits better to separate the names from regular text (even though it's not required).

doc/testing.md line 664:

> 662: select Registry Editor; navigate to the following key:
> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`; make sure
> 664: its value is set to 0.

Suggestion:

On Windows there is a delay in focus transfer. Usually it causes automated
UI test failure. To disable the delay, type `regedit` in the Search and then
select Registry Editor; navigate to the following key:
`HKEY_CURRENT_USER\Control Panel\Desktop`; make sure
the `ForegroundLockTimeout` value is set to 0.

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From serb at openjdk.org  Mon Feb 27 20:57:29 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Feb 2023 20:57:29 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>

On Mon, 27 Feb 2023 15:54:28 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Added the section devoted to client UI test which use Robot API

doc/testing.html line 621:

> 619: the following apps are allowed to control your computer:
> 620: <code>Java</code> and <code>Terminal</code>. If the tests are run from
> 621: an IDE, the IDE should be granted this permission too.</p>

You can mention the tests which can be used to verify that the UI, sound, etc are configured properly.(it was done somewhere before one test per option)

doc/testing.md line 664:

> 662: select Registry Editor; navigate to the following key:
> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`; make sure
> 664: its value is set to 0.

Probably it should mention that this is a workaround for the usage of Cygwin:
https://bugs.openjdk.org/browse/CODETOOLS-7901623

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From aivanov at openjdk.org  Mon Feb 27 21:15:03 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 21:15:03 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
In-Reply-To: <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
Message-ID: <dWXQHuN0ViKAvbZhH1fvJxDmAH09p5eaL8KTDZS7tmM=.c1109823-9d44-46d3-9cc6-0d786e5d99d9@github.com>

On Mon, 27 Feb 2023 20:54:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> doc/testing.html line 621:
> 
>> 619: the following apps are allowed to control your computer:
>> 620: <code>Java</code> and <code>Terminal</code>. If the tests are run from
>> 621: an IDE, the IDE should be granted this permission too.</p>
> 
> You can mention the tests which can be used to verify that the UI, sound, etc are configured properly.(it was done somewhere before one test per option)

It is mentioned on an internal wiki page.

More detailed instructions are available at the [Automated client GUI testing system set up requirements](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements) wiki page of the Client Libraries.

This page should likely link to it.

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From prr at openjdk.org  Mon Feb 27 23:05:09 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 27 Feb 2023 23:05:09 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
Message-ID: <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>

On Mon, 27 Feb 2023 16:16:50 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
>> 
>> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
>> 
>> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
>> 
>> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 126:

> 124: # about initializing a declared 'extern' cannot be turned off individually. Only
> 125: # applies to debug builds. This limitation in gcc is tracked in
> 126: # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977

The comment above needs to be moved inside the if block because it only applies to the first setting, not the second.

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 130:

> 128:   BUILD_LIBAWT_debug_mem.c_CFLAGS := -w
> 129:   # This option improves performance of FillRect/FillOval in Java2D by 15% for some gcc
> 130:   LIBAWT_CFLAGS += -fpic

So .. acc. to the eval in JBS we can get rid of -fgcse-after-reload because it is implied by -O3
And Erik says -fPIC is implied by -fpic 

So how is -fpic different than -fPIC in a way that helps here ?
So far as I can tell the -fpic are using just limits the size of the global offset table that -fPIC will generate.
Since we had an unlimited offset table before, then -fpic won't change anything. 
So what's the explanation ?

-------------

PR: https://git.openjdk.org/jdk/pull/12761


From jdv at openjdk.org  Tue Feb 28 06:50:05 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 28 Feb 2023 06:50:05 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
 <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
Message-ID: <ZKhjLFnOiE_YK5D0W63vlWS8pNXaC_vAK7uMsb-XX3w=.717990e5-056e-4987-a5d0-d71e1db6456c@github.com>

On Mon, 27 Feb 2023 23:02:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 130:
> 
>> 128:   BUILD_LIBAWT_debug_mem.c_CFLAGS := -w
>> 129:   # This option improves performance of FillRect/FillOval in Java2D by 15% for some gcc
>> 130:   LIBAWT_CFLAGS += -fpic
> 
> So .. acc. to the eval in JBS we can get rid of -fgcse-after-reload because it is implied by -O3
> And Erik says -fPIC is implied by -fpic 
> 
> So how is -fpic different than -fPIC in a way that helps here ?
> So far as I can tell the -fpic are using just limits the size of the global offset table that -fPIC will generate.
> Since we had an unlimited offset table before, then -fpic won't change anything. 
> So what's the explanation ?

Thanks @prrace for your inputs.
I dont think -fPIC is implied by -fpic. @erikj79  please clarify.

Difference between -fpic and -fPIC:
1) With -fPIC we have unlimited storage capacity for global offset table and with -fpic on some platforms we have limitation on this size. For aarch64 it is 28k, but in case of x86 size of GOT is unlimited irrespective of -fPIC or -fpic. This is already captured.
2) Also it looks like if we use -fpic option instead of -fPIC we may generate smaller/faster code as mentioned at http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html. Looks like in our case, 28k GOT size suffices and we are able to create smaller/faster code for libawt in case of aarch64. This inturn looks to be related to usage of -msmall-data or -mlarge-data flags. -fpic implies -msmall-data and -fPIC implies -mlarge-data while generating code for shared libraries. -msmall-data also talks about data being nearer and easily accessible compared to  -mlarge-data(https://man7.org/linux/man-pages/man1/gcc.1.html)

Also i can make this change specific to aarch64 since we are seeing its effect only on aarch64.

-------------

PR: https://git.openjdk.org/jdk/pull/12761


From jdv at openjdk.org  Tue Feb 28 06:55:36 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 28 Feb 2023 06:55:36 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v3]
In-Reply-To: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
Message-ID: <iQV2krpbZWIo9qMv7o9Hpa4BokiURJM2XX5OBzxBex8=.cd5fa1bf-5bdd-4d40-a636-a9e0b16a3837@github.com>

> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
> 
> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
> 
> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
> 
> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Shift comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12761/files
  - new: https://git.openjdk.org/jdk/pull/12761/files/e8d25674..135883db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=01-02

  Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12761/head:pull/12761

PR: https://git.openjdk.org/jdk/pull/12761


From jdv at openjdk.org  Tue Feb 28 06:55:36 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 28 Feb 2023 06:55:36 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
 <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
Message-ID: <gPGH5ajauIdjOmbX78IW8tC-tP2hwf4YmsfEZpPFp2I=.aa236871-a050-455b-afc8-1e0b01c352bd@github.com>

On Mon, 27 Feb 2023 22:58:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 126:
> 
>> 124: # about initializing a declared 'extern' cannot be turned off individually. Only
>> 125: # applies to debug builds. This limitation in gcc is tracked in
>> 126: # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977
> 
> The comment above needs to be moved inside the if block because it only applies to the first setting, not the second.

Updated

-------------

PR: https://git.openjdk.org/jdk/pull/12761


From dmarkov at openjdk.org  Tue Feb 28 11:03:41 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:41 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>

> Added the section devoted to client UI test which use Robot API

Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:

  Fix review findings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12772/files
  - new: https://git.openjdk.org/jdk/pull/12772/files/1774d37a..e1ec5f9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=00-01

  Stats: 40 lines in 2 files changed: 8 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/12772.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12772/head:pull/12772

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 11:03:41 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:41 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <fnTQ2BBCx8-dOddhwfLDMRWn6qkSvUO76fPk15W4Zjg=.b5ed2cb0-427e-4b4c-bf03-40da37edf2d9@github.com>

On Mon, 27 Feb 2023 15:54:28 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Added the section devoted to client UI test which use Robot API

@aivanov-jdk @mrserb Thanks for review. I have updated the text based on your suggestions. Please have a look at the new version.

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 11:03:42 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:42 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <dWXQHuN0ViKAvbZhH1fvJxDmAH09p5eaL8KTDZS7tmM=.c1109823-9d44-46d3-9cc6-0d786e5d99d9@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
 <dWXQHuN0ViKAvbZhH1fvJxDmAH09p5eaL8KTDZS7tmM=.c1109823-9d44-46d3-9cc6-0d786e5d99d9@github.com>
Message-ID: <3Jm3v2Vktc0LRQU72wnjTcnu_706DgO7GQaN_49dBLQ=.d106ef06-c373-428d-b862-3a68c9efa134@github.com>

On Mon, 27 Feb 2023 21:11:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> doc/testing.html line 621:
>> 
>>> 619: the following apps are allowed to control your computer:
>>> 620: <code>Java</code> and <code>Terminal</code>. If the tests are run from
>>> 621: an IDE, the IDE should be granted this permission too.</p>
>> 
>> You can mention the tests which can be used to verify that the UI, sound, etc are configured properly.(it was done somewhere before one test per option)
>
> It is mentioned on an internal wiki page.
> 
> More detailed instructions are available at the [Automated client GUI testing system set up requirements](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements) wiki page of the Client Libraries.
> 
> This page should likely link to it.

I have added the link to the wiki

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 11:03:42 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:42 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <QZ4iENrRYXUbzM0yYnUaF1kZMxwkysqRQWklkD17t44=.6c5bc8e4-da8a-44e9-bf37-358ff8b5d631@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <QZ4iENrRYXUbzM0yYnUaF1kZMxwkysqRQWklkD17t44=.6c5bc8e4-da8a-44e9-bf37-358ff8b5d631@github.com>
Message-ID: <tlrdS2ZvYrjmdCU-3oGe0ad6OKS-Hk_FXYP2wtOYyvg=.fc38f38c-107d-4fa6-8f14-fffff2b1fe45@github.com>

On Mon, 27 Feb 2023 18:49:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review findings
>
> doc/testing.md line 616:
> 
>> 614: system key shortcuts for various platforms are provided below.
>> 615: 
>> 616: ##### MacOS
> 
> Suggestion:
> 
> ##### macOS
> 
> Shall we spell _macOS_ with lower-case ?m? like Apple does?

Done

> doc/testing.md line 648:
> 
>> 646: the default operating system settings need to be adjusted for correct work of
>> 647: Robot functionality. The detailed steps how to access and update that settings
>> 648: for different platforms are provided below.
> 
> Suggestion:
> 
> Most automated Client UI tests use `Robot` API to control the UI. Usually,
> the default operating system settings need to be adjusted for Robot
> to work correctly. The detailed steps how to access and update these settings
> for different platforms are provided below.

Fixed

> doc/testing.md line 656:
> 
>> 654: Privacy & Security; select Accessibility and ensure the following apps are
>> 655: allowed to control your computer: `Java` and `Terminal`. If the tests are run
>> 656: from an IDE, the IDE should be granted this permission too.
> 
> Suggestion:
> 
> `Robot` is not permitted to control your Mac by default since
> macOS 10.15. To enable it, choose Apple menu > System Settings, click
> Privacy & Security, then click Accessibility and ensure the following apps are
> allowed to control your computer: *Java* and *Terminal*. If the tests are run
> from an IDE, the IDE should be granted this permission too.
> 
> I amended the instructions align with [Allow accessibility apps to access your Mac](https://support.apple.com/en-gb/guide/mac-help/mh43185/mac).
> 
> Perhaps, ?to allow it? is better than ?to enable it?. Also unsure about ?`Robot` is not *allowed* to control?? instead of ?permitted?.
> 
> *Java* and *Terminal* are the names of apps, not part of a command-line, therefore they're shouldn't be rendered in monospace font; using italics suits better to separate the names from regular text (even though it's not required).

Fixed

> doc/testing.md line 664:
> 
>> 662: select Registry Editor; navigate to the following key:
>> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`; make sure
>> 664: its value is set to 0.
> 
> Suggestion:
> 
> On Windows there is a delay in focus transfer. Usually it causes automated
> UI test failure. To disable the delay, type `regedit` in the Search and then
> select Registry Editor; navigate to the following key:
> `HKEY_CURRENT_USER\Control Panel\Desktop`; make sure
> the `ForegroundLockTimeout` value is set to 0.

Fixed

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 11:03:42 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:42 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
Message-ID: <7lHleflYaOFpVAE9BmAr74Bx9nPlP1JenM8_rY5_BuI=.347a98a3-0ba8-48ed-8a35-9f1d22d3fac7@github.com>

On Mon, 27 Feb 2023 20:52:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review findings
>
> doc/testing.md line 664:
> 
>> 662: select Registry Editor; navigate to the following key:
>> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`; make sure
>> 664: its value is set to 0.
> 
> Probably it should mention that this is a workaround for the usage of Cygwin:
> https://bugs.openjdk.org/browse/CODETOOLS-7901623

Done

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From chen.j.patrick at gmail.com  Tue Feb 28 13:35:42 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Tue, 28 Feb 2023 14:35:42 +0100
Subject: RFR: 8303130: Document required Accessibility permissions on
 macOS [v2]
In-Reply-To: <7lHleflYaOFpVAE9BmAr74Bx9nPlP1JenM8_rY5_BuI=.347a98a3-0ba8-48ed-8a35-9f1d22d3fac7@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
 <7lHleflYaOFpVAE9BmAr74Bx9nPlP1JenM8_rY5_BuI=.347a98a3-0ba8-48ed-8a35-9f1d22d3fac7@github.com>
Message-ID: <CANmuJ8tRCnxufnAX+oQYwK=7Q4NQuy2DCW7Yf+q5E0sr-feTSw@mail.gmail.com>

pre submit tests failed

Le mar. 28 f?vr. 2023 ? 12:04, Dmitry Markov <dmarkov at openjdk.org> a ?crit :

> On Mon, 27 Feb 2023 20:52:52 GMT, Sergey Bylokhov <serb at openjdk.org>
> wrote:
>
> >> Dmitry Markov has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >>   Fix review findings
> >
> > doc/testing.md line 664:
> >
> >> 662: select Registry Editor; navigate to the following key:
> >> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`;
> make sure
> >> 664: its value is set to 0.
> >
> > Probably it should mention that this is a workaround for the usage of
> Cygwin:
> > https://bugs.openjdk.org/browse/CODETOOLS-7901623
>
> Done
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12772
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230228/b0b2e8bf/attachment.htm>

From erikj at openjdk.org  Tue Feb 28 14:00:16 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 28 Feb 2023 14:00:16 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <ZKhjLFnOiE_YK5D0W63vlWS8pNXaC_vAK7uMsb-XX3w=.717990e5-056e-4987-a5d0-d71e1db6456c@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
 <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
 <ZKhjLFnOiE_YK5D0W63vlWS8pNXaC_vAK7uMsb-XX3w=.717990e5-056e-4987-a5d0-d71e1db6456c@github.com>
Message-ID: <9oErSGZO2hcusvCEEV2eJTgmev_v-5OJclGdyyLwPJg=.2f44899a-2a76-42c1-bde7-b180c5b991ef@github.com>

On Tue, 28 Feb 2023 06:47:37 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 130:
>> 
>>> 128:   BUILD_LIBAWT_debug_mem.c_CFLAGS := -w
>>> 129:   # This option improves performance of FillRect/FillOval in Java2D by 15% for some gcc
>>> 130:   LIBAWT_CFLAGS += -fpic
>> 
>> So .. acc. to the eval in JBS we can get rid of -fgcse-after-reload because it is implied by -O3
>> And Erik says -fPIC is implied by -fpic 
>> 
>> So how is -fpic different than -fPIC in a way that helps here ?
>> So far as I can tell the -fpic are using just limits the size of the global offset table that -fPIC will generate.
>> Since we had an unlimited offset table before, then -fpic won't change anything. 
>> So what's the explanation ?
>
> Thanks @prrace for your inputs.
> I dont think -fPIC is implied by -fpic. @erikj79  please clarify.
> 
> Difference between -fpic and -fPIC:
> 1) With -fPIC we have unlimited storage capacity for global offset table and with -fpic on some platforms we have limitation on this size. For aarch64 it is 28k, but in case of x86 size of GOT is unlimited irrespective of -fPIC or -fpic. This is already captured.
> 2) Also it looks like if we use -fpic option instead of -fPIC we may generate smaller/faster code as mentioned at http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html. Looks like in our case, 28k GOT size suffices and we are able to create smaller/faster code for libawt in case of aarch64. This inturn looks to be related to usage of -msmall-data or -mlarge-data flags. -fpic implies -msmall-data and -fPIC implies -mlarge-data while generating code for shared libraries. -msmall-data also talks about data being nearer and easily accessible compared to  -mlarge-data(https://man7.org/linux/man-pages/man1/gcc.1.html)
> 
> Also i can make this change specific to aarch64 since we are seeing its effect only on aarch64.

I think you have read more about the differences between -fpic and -fPIC than I have, so nothing I can add here.

Making this option only on aarch64 seems like a reasonable idea if that's where we see the effect.

-------------

PR: https://git.openjdk.org/jdk/pull/12761


From erikj at openjdk.org  Tue Feb 28 14:03:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 28 Feb 2023 14:03:17 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>
Message-ID: <cQTyIKyCrpidBC_8P011yzgAiS-erhjLdEAuwqPcoGU=.ebe11442-ce03-48cf-b273-a9d501d2020d@github.com>

On Tue, 28 Feb 2023 11:03:41 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review findings

doc/testing.md line 666:

> 664: the `ForegroundLockTimeout` value is set to 0.
> 665: 
> 666: Additional information about Client UI tests configuration for vrious operating

Suggestion:

Additional information about Client UI tests configuration for various operating

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From asotona at openjdk.org  Tue Feb 28 14:13:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 14:13:02 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <K6w7vBBPpKz30feZIbgFNfjMhIFfle8RT87XgCYyCjw=.1fc7973b-529e-482d-a459-ac02b66e9901@github.com>
Message-ID: <WklxQuifDr3hfm1Nb9cVtbMG7wgXDz_baMWM2LxNVCs=.867d191c-70a5-4bd9-957b-72d56aa6d6b3@github.com>

On Thu, 16 Feb 2023 12:55:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 217:
> 
>> 215:                 }
>> 216:             };
>> 217:             // Doing a full scan here yields fall-off-the-cliff performance results,
> 
> Understanding checkpoint: the parent is a class reader, which holds some class bytes. The class reader is set up in a way that constant pool entries are read "on-demand" - that is, if I ask the class reader "give me CP entry 42", the classreader will only build that entry (assuming 42 is a valid index) and give me back that entry. Also, the class reader will save the read constant in an internal array, to avoid re-reading the classfile bytes multiple times.
> 
> So, what this code here does is: when we create an entry map, we populate the map with the entries from the parent reader - but we only add entries that were already looked up (e.g. we do not bother reading _all_ entries, and adding all of them to the entry map).
> 
> But, when `findEntry` is called, if we see that we can't find the entry, and we know that there might be constant pool entries from the parent reader still unread, we force a full scan of the parent reader pool and try again.
> 
> Correct?

Right, it is a multi-stage inflation, where partial-only inflation improves performance of frequent use cases significantly and full scan is a fall-back.

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From dmarkov at openjdk.org  Tue Feb 28 14:17:11 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 14:17:11 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v3]
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>

> Added the section devoted to client UI test which use Robot API

Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12772/files
  - new: https://git.openjdk.org/jdk/pull/12772/files/e1ec5f9e..1ce9b932

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12772.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12772/head:pull/12772

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 14:17:16 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 14:17:16 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <cQTyIKyCrpidBC_8P011yzgAiS-erhjLdEAuwqPcoGU=.ebe11442-ce03-48cf-b273-a9d501d2020d@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>
 <cQTyIKyCrpidBC_8P011yzgAiS-erhjLdEAuwqPcoGU=.ebe11442-ce03-48cf-b273-a9d501d2020d@github.com>
Message-ID: <2tEkfzVYky3Z-OFDWk359U64nLZuVMS7yg5zzU3uZ1s=.5fe538b7-f4e7-4b72-94d1-333bca1816fb@github.com>

On Tue, 28 Feb 2023 14:00:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review findings
>
> doc/testing.md line 666:
> 
>> 664: the `ForegroundLockTimeout` value is set to 0.
>> 665: 
>> 666: Additional information about Client UI tests configuration for vrious operating
> 
> Suggestion:
> 
> Additional information about Client UI tests configuration for various operating

Fixed

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From asotona at openjdk.org  Tue Feb 28 14:23:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 14:23:24 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <Zxf7g-vn0s38BsgM_KaED6NmCIgrDnNuk6Zq7OEh2IU=.207180e4-83d0-4a7b-ac43-1e9ffacdd686@github.com>

On Thu, 16 Feb 2023 13:40:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 75:
> 
>> 73:     static ConstantPoolBuilder of(ClassModel classModel) {
>> 74:         ClassReader reader = (ClassReader) classModel.constantPool();
>> 75:         return reader.optionValue(Classfile.Option.Key.CP_SHARING)
> 
> Question: the fact that, when transforming, the new constant pool is the same as the old one, plus some "appended" entries at the end, is a pretty crucial property to ensure that existing code that is not transformed (e.g. unknown attributes) remains legal after transformation. But it seems that, if the `CP_SHARING` option is not passed, we build a brand new constant pool, in which case there's no guarantee that old indices will still point to the same position. Doesn't that lead to issue with unknown attributes?
> 
> I guess my question is: shouldn't the semantics properties/guarantees of a classfile transform be specified regardless of the options being passed in? E.g. it's ok if using different options ends up with different performance model, but I'm a bit worried if options can affect correctness of the transform?

If you propose `constantPoolSharing(false)` should automatically imply `processUnknownAttributes(false)` - it would avoid potential invalid CP entries in the unknown attributes and we may consider that dependency between the two options.
However on the other side there might be unknown attributes completely independent of CP and for such the transformation is safe. Strong options implication would force users to create custom attribute mappers for such attributes.
Current options independence gives user power to configure transformations flexibly, however on the other side it allows to produce classes with invalid CP entries in unknown attributes.

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Tue Feb 28 14:37:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 14:37:47 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <dy09oa0LABN_9yw4UZp3PDDpGwLtD8Vip0wWDJ3v1_0=.38c04f5b-e517-4113-ab33-effeb255aa6e@github.com>

On Thu, 16 Feb 2023 13:47:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 38:
> 
>> 36:     private final List<Attribute<?>> attributes = new ArrayList<>();
>> 37: 
>> 38:     public AttributeHolder() {
> 
> default constructor

yes, it is a default constructor, do you suggest to remove it?

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From chen.j.patrick at gmail.com  Tue Feb 28 15:23:16 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Tue, 28 Feb 2023 16:23:16 +0100
Subject: RFR: 8303130: Document required Accessibility permissions on
 macOS [v2]
In-Reply-To: <2tEkfzVYky3Z-OFDWk359U64nLZuVMS7yg5zzU3uZ1s=.5fe538b7-f4e7-4b72-94d1-333bca1816fb@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>
 <cQTyIKyCrpidBC_8P011yzgAiS-erhjLdEAuwqPcoGU=.ebe11442-ce03-48cf-b273-a9d501d2020d@github.com>
 <2tEkfzVYky3Z-OFDWk359U64nLZuVMS7yg5zzU3uZ1s=.5fe538b7-f4e7-4b72-94d1-333bca1816fb@github.com>
Message-ID: <CANmuJ8sL2d5+O61jh5hHoOfSfjz=Wo1GzL2NMheAgV6oZRQU1A@mail.gmail.com>

lgtm


Le mar. 28 f?vr. 2023 ? 15:18, Dmitry Markov <dmarkov at openjdk.org> a ?crit :

> On Tue, 28 Feb 2023 14:00:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:
>
> >> Dmitry Markov has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >>   Fix review findings
> >
> > doc/testing.md line 666:
> >
> >> 664: the `ForegroundLockTimeout` value is set to 0.
> >> 665:
> >> 666: Additional information about Client UI tests configuration for
> vrious operating
> >
> > Suggestion:
> >
> > Additional information about Client UI tests configuration for various
> operating
>
> Fixed
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12772
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230228/b2b25764/attachment.htm>

From mcimadamore at openjdk.org  Tue Feb 28 15:33:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Feb 2023 15:33:08 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <dy09oa0LABN_9yw4UZp3PDDpGwLtD8Vip0wWDJ3v1_0=.38c04f5b-e517-4113-ab33-effeb255aa6e@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
 <dy09oa0LABN_9yw4UZp3PDDpGwLtD8Vip0wWDJ3v1_0=.38c04f5b-e517-4113-ab33-effeb255aa6e@github.com>
Message-ID: <iNzjTSVc4ZGs_KXdwxPPnwmhnhRyc0ygAT7iFN8mzCs=.a03ee9dc-9d3a-49a7-a09d-ed0cc07fafc2@github.com>

On Tue, 28 Feb 2023 14:33:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 38:
>> 
>>> 36:     private final List<Attribute<?>> attributes = new ArrayList<>();
>>> 37: 
>>> 38:     public AttributeHolder() {
>> 
>> default constructor
>
> yes, it is a default constructor, do you suggest to remove it?

Yes, it's inside the implementation, it's not like it's used as a placeholder for javadoc or anything?

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Tue Feb 28 16:02:35 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 16:02:35 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v28]
In-Reply-To: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
Message-ID: <gn9i38a6nzEV47JphuQyTIZKHiEtooPCsphRtCWmJpc=.1643778c-762a-4944-bf3d-11a73aa4d266@github.com>

> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
> 
> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
> 
> Classfile API development is tracked at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
> 
> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
> 
> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
> 
> Please take you time to review this non-trivial JDK addition.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - BytecodeHelpers fix
 - javadoc and long lines fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10982/files
  - new: https://git.openjdk.org/jdk/pull/10982/files/7002d719..58c9d2c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=26-27

  Stats: 35 lines in 4 files changed: 15 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Tue Feb 28 16:02:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 16:02:45 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <50yzjqQcSR2lSq7mh-eV1gY6jX8bVtLIq3xBG21IedI=.8fa3a973-87f9-4507-a168-0ce358c7770a@github.com>

On Thu, 16 Feb 2023 13:43:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 54:
> 
>> 52:  */
>> 53: public class BytecodeHelpers {
>> 54: //    public static Map<ConstantDesc, Opcode> constantsToOpcodes = new HashMap<>(16);
> 
> Should this be removed?

yes, fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 56:
> 
>> 54: //    public static Map<ConstantDesc, Opcode> constantsToOpcodes = new HashMap<>(16);
>> 55: 
>> 56:     public BytecodeHelpers() {
> 
> Should this also be removed (same as default constructor) ?

I set the constructor to private as there are no instances created.

> src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 30:
> 
>> 28:  * An open-chain multimap used to map nonzero hashes to indexes (of either CP
>> 29:  * elements or BSM entries).  Code transformed from public domain implementation
>> 30:  * (http://java-performance.info/implementing-world-fastest-java-int-to-int-hash-map/).
> 
> Could not open this link - seems to redirect to main page

Direct link does not work, I've fixed it to point to the home page.

> src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 192:
> 
>> 190:         return (int)s;
>> 191:     }
>> 192: }
> 
> Watch for newlines

fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Tue Feb 28 16:20:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 16:20:06 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <LdTyBMeXb0wC8SSMsKaYiA96EfJdCdAWKpjACqq4EhU=.147fc67f-9e40-4184-b5f6-da6865c042f6@github.com>

On Thu, 16 Feb 2023 14:41:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ConcreteEntry.java line 58:
> 
>> 56: import jdk.internal.classfile.jdktypes.PackageDesc;
>> 57: 
>> 58: public abstract sealed class ConcreteEntry {
> 
> Why the name `concrete` ? Am I missing something (e.g. existence of "non-concrete" pool entries?)

XyzEntryImpl naming convention would be better, I'll adjust it.

> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 658:
> 
>> 656:             mruParent = parent;
>> 657:             mruParentTable = table;
>> 658:             return mruParentTable[lab.getContextInfo()] - 1;
> 
> Am I correct that this code can misbehave e.g. if `computeIfAbsent` ends up creating a brand new `table` array - in which case, all array elements are set to `0` - meaning we end up returning `-1`. Is that what we want?

Yes, -1 indicates the label has not been resolved yet.

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From asotona at openjdk.org  Tue Feb 28 16:25:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 Feb 2023 16:25:25 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v20]
In-Reply-To: <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <Gluemo5fFOPx_G6KtSgHxWEmiv3FFSTlxRHtc6ZPTuc=.6a2b6930-c7fd-4734-b21b-d2ccec1dabcf@github.com>
 <01V72lRVYH7rB1NrPpkVKhvj1mksmrelMMTMrHFQ2hk=.4b2c22f3-d9c6-4778-be53-1fb055969f6a@github.com>
Message-ID: <3ywCIdn2B1u8zBJqrwo97WEuDeuo4anQFScLoq5B85I=.f5140ddb-03d0-4bd2-9d87-be7e97a297dd@github.com>

On Thu, 16 Feb 2023 14:47:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/InstructionData.java line 47:
> 
>> 45:  * InstructionData
>> 46:  */
>> 47: public class InstructionData {
> 
> As CodeImpl seems to be the only client of this, I wonder if we could move the static cache in there?

yes, will fix it

> src/java.base/share/classes/jdk/internal/classfile/impl/LabelImpl.java line 65:
> 
>> 63: 
>> 64:     public int getContextInfo() {
>> 65:         return contextInfo;
> 
> This seems to be the BCI - should we change names to reflect that? (`contextInfo` seems very vague)

yes, will fix it

-------------

PR: https://git.openjdk.org/jdk/pull/10982


From alanb at openjdk.org  Tue Feb 28 16:36:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 16:36:04 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
Message-ID: <h6u-lTg178nqjVPNoN9VBw61700dNJcYz5PLglQD2fA=.3f2a9c90-5419-4df7-8ee7-9b9f521924cb@github.com>

On Wed, 22 Feb 2023 17:40:31 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to add file
>  - Resolve review comments

src/java.base/windows/native/libnet/NetworkInterface.c line 144:

> 142:                         uniAddrs->Table[i].DadState == IpDadStateDeprecated)) {
> 143:             addrCount++;
> 144:             addrsCurrent = malloc(sizeof(netaddr));

Can you do a pass over this to handle the case where malloc fails?

-------------

PR: https://git.openjdk.org/jdk/pull/12593


From erikj at openjdk.org  Tue Feb 28 16:39:44 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 28 Feb 2023 16:39:44 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v3]
In-Reply-To: <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
Message-ID: <t1j1uipy8QKtVfBRpzf8xk0u1jlOcVFCq6oAt231ih0=.814475bb-70cb-4cf0-b869-21eb36f715e1@github.com>

On Tue, 28 Feb 2023 14:17:11 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From aivanov at openjdk.org  Tue Feb 28 16:49:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 28 Feb 2023 16:49:53 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v3]
In-Reply-To: <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
Message-ID: <y8pmcfwxfKBgkJXKjmAoivg4VtAxwieeeNcsV-elHew=.1638bbef-3dd0-44e7-88ae-252cf0cf153e@github.com>

On Tue, 28 Feb 2023 14:17:11 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Changes requested by aivanov (Reviewer).

doc/testing.md line 668:

> 666: Additional information about Client UI tests configuration for various operating
> 667: systems can be obtained at [Automated client GUI testing system set up
> 668: requirements] (https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)

Suggestion:

requirements](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)


Because of the space, the link didn't get converted as expected, the HTML output contains `[]` followed by the link in `()`.

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 17:03:01 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 17:03:01 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v4]
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>

> Added the section devoted to client UI test which use Robot API

Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:

  Fix link

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12772/files
  - new: https://git.openjdk.org/jdk/pull/12772/files/1ce9b932..1a3e0419

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=02-03

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12772.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12772/head:pull/12772

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 17:03:05 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 17:03:05 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v3]
In-Reply-To: <y8pmcfwxfKBgkJXKjmAoivg4VtAxwieeeNcsV-elHew=.1638bbef-3dd0-44e7-88ae-252cf0cf153e@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
 <y8pmcfwxfKBgkJXKjmAoivg4VtAxwieeeNcsV-elHew=.1638bbef-3dd0-44e7-88ae-252cf0cf153e@github.com>
Message-ID: <b23sQjrPOLKNspjPFrb6Tpw0gAXU63_fDuvG3ErVK4U=.3d0dcb23-ab7b-4ddb-bbf2-c363feb06d81@github.com>

On Tue, 28 Feb 2023 16:45:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> doc/testing.md line 668:
> 
>> 666: Additional information about Client UI tests configuration for various operating
>> 667: systems can be obtained at [Automated client GUI testing system set up
>> 668: requirements] (https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)
> 
> Suggestion:
> 
> requirements](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)
> 
> 
> Because of the space, the link didn't get converted as expected, the HTML output contains `[]` followed by the link in `()`.

Done

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From aivanov at openjdk.org  Tue Feb 28 17:17:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 28 Feb 2023 17:17:13 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v4]
In-Reply-To: <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
Message-ID: <mA7FDtKTUu5_LBCwvN-TmgUEQpdpmx34mEkD0HfyPV8=.dd0a3fbf-6659-4184-9c1b-c76ee098a318@github.com>

On Tue, 28 Feb 2023 17:03:01 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From alanb at openjdk.org  Tue Feb 28 18:00:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 18:00:17 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
Message-ID: <xGnUVdb5CG0mmJlLRgOTKUAHsJgotxvGd57Q7KxGs24=.da61589e-0087-4d77-bb56-a4849503ac2e@github.com>

On Wed, 22 Feb 2023 17:40:31 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to add file
>  - Resolve review comments

src/java.base/windows/native/libnet/NetworkInterface.c line 646:

> 644:     since multicast is unlikely to be disabled,
> 645:     and a boolean can't represent the full range of possibilities anyway.
> 646:     */

I don't think it's useful to include the historical note. Instead, I think reduce this down to a line or two to say that it optimistically assumes multicast is enabled.

-------------

PR: https://git.openjdk.org/jdk/pull/12593


From prr at openjdk.org  Tue Feb 28 19:12:05 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 19:12:05 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v4]
In-Reply-To: <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
Message-ID: <c-2eA6D-WcIGwnvngrl2QeZh4UVmzgTTQM-eidAPjsc=.a9b587e4-507e-430b-bb53-3817cb76380f@github.com>

On Tue, 28 Feb 2023 17:03:01 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From serb at openjdk.org  Tue Feb 28 19:12:06 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Feb 2023 19:12:06 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v4]
In-Reply-To: <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
Message-ID: <N52UOlQmd4hVNtr3s76fk1ff1gf3s9GfIFp0p88VFQc=.b57ac0bf-a883-4f35-a6df-49cb4bb0540b@github.com>

On Tue, 28 Feb 2023 17:03:01 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link

Thank you for this doc update.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12772


From alanb at openjdk.org  Tue Feb 28 19:13:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Feb 2023 19:13:12 GMT
Subject: RFR: 8302659: Modernize Windows native code for NetworkInterface
 [v3]
In-Reply-To: <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
References: <44bJpV9Ik-SpmLh9RQ-fw4ctucRghAQKkO8nPPO3-eY=.e7054dc8-a959-47dd-a3b7-8764730e59d7@github.com>
 <aDDMgqVIix5j7CMSJ8nie1-PceRSyjEIeTBk4ybPPg8=.1cb7022d-2b09-4cf2-a91f-77f14c75a0d2@github.com>
Message-ID: <N1Dqax1FFbuBAiHr8PqtYhLonMXd_vAPbCiqxptS4Og=.9ca3819f-ffc1-4ef3-b6cd-d93aa27b641d@github.com>

On Wed, 22 Feb 2023 17:40:31 GMT, Rich DiCroce <duke at openjdk.org> wrote:

>> Improves performance and correctness, as discussed on the net-dev mailing list.
>
> Rich DiCroce has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Forgot to add file
>  - Resolve review comments

Overall I think this is a very contribution. It's good to modernize this code and remove the cruft that dates from before many of the new APIs were added.

I suspect we will need a release document any behaviour changes that may be observed when upgrading the JDK. In particular, the network interface names will look different. The synthesized names were names like "lo" and "eth0" whereas the new names come from Windows (names like "lookup_0" and "ethernet_0"). I haven't found tools that show the names that ConvertInterfaceLuidToNameW returns but if there are then the RN could mention it. On other platforms, it would be was easy for configuration to name the interface to be used for multicasting, it doesn't seem easy to do the same on Windows and application might have to resort to configuration by IP address.

I'm not too concerned that interfaces without IP addresses are enumerated. They aren't useful for multicasting applications but maybe they are useful for informational purposes, e.g. programs that collect system environment. I'm also not too concern about the ordering of the IP addresses. I'll defer to @djelinski on whether some JDK tests or test infra needs to be updated in advance to ensure that tests that choose interfaces will continue to work.

-------------

PR: https://git.openjdk.org/jdk/pull/12593


From jwaters at openjdk.org  Tue Feb 28 19:22:57 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 28 Feb 2023 19:22:57 GMT
Subject: RFR: 8295884: Implement IDE support for Eclipse [v32]
In-Reply-To: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
References: <zGkxT4ajd4aCpTWZw3uXY5VHMAoBjEc7UBInHd_mAA0=.32e6143f-c24d-464f-ab28-0dbc84b08c30@github.com>
Message-ID: <NFvZu1tPiieo55l_l0q108ElH4vxRwcYY53bN8BJQhs=.88711bc5-0f73-499c-be23-fe526dd67806@github.com>

> Eclipse is a popular and very well-known IDE in the world of Java development, utilized widely in many contexts, by beginners and experienced teams alike. Although a relatively lightweight IDE, it features surprisingly powerful indexing and code analysis capabilities, as well as useful tools, among which are make integration. While the tools it provides are not always as sophisticated as other IDEs (IntelliJ IDEA will likely come to mind as one such competitor), the simplicity of using it, as well as the reliability of this rugged IDE makes up greatly for the slightly less advanced tooling. Eclipse requires very little starting infrastructure in the workspace for all these features and indexing support as well, which makes it a good candidate for developing on the JDK.
> 
> This enhancement adds 4 extra targets to the make system for generating a basic Eclipse Workspace that provides almost full indexing support for the JDK, with varying levels as desired, from a minimalistic option only including the Java Virtual Machine's source code, to generating a workspace with both Java and C/C++ natures included, which allows for using Eclipse's unique ability to quickly swap between Java and C/C++ mode to work on both native and Java sources at the same time. Cross Compiling support is available, and in its entirety the change touches very little of the existing make system, barring its own Makefile within the ide subdirectory.
> 
> Indexing capabilities utilizing the enhancement:
> <img width="960" alt="java" src="https://user-images.githubusercontent.com/32636402/197784819-67ec7de4-7e27-4f33-b738-59b75a9e4403.PNG">
> <img width="787" alt="escape" src="https://user-images.githubusercontent.com/32636402/197784843-df8621a8-7b0a-42da-86f4-3afb92de0f71.PNG">

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  classpaths now use templates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10853/files
  - new: https://git.openjdk.org/jdk/pull/10853/files/0d3dfb9b..765fb2fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10853&range=30-31

  Stats: 134 lines in 5 files changed: 121 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10853.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10853/head:pull/10853

PR: https://git.openjdk.org/jdk/pull/10853


From dmarkov at openjdk.org  Tue Feb 28 19:54:28 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 19:54:28 GMT
Subject: Integrated: 8303130: Document required Accessibility permissions on
 macOS
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <Lvpsdv96WuN6bWghsGkNEZj-ZF975F987R3O1ZivDAU=.58dbe662-b2fa-406b-a07a-883cae5e61b5@github.com>

On Mon, 27 Feb 2023 15:54:28 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Added the section devoted to client UI test which use Robot API

This pull request has now been integrated.

Changeset: a10d5ac6
Author:    Dmitry Markov <dmarkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a10d5ac61be3d074937f629959c7aeb694147203
Stats:     60 lines in 2 files changed: 54 ins; 0 del; 6 mod

8303130: Document required Accessibility permissions on macOS

Reviewed-by: erikj, aivanov, prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/12772


From prr at openjdk.org  Tue Feb 28 20:48:08 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 20:48:08 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <9oErSGZO2hcusvCEEV2eJTgmev_v-5OJclGdyyLwPJg=.2f44899a-2a76-42c1-bde7-b180c5b991ef@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
 <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
 <ZKhjLFnOiE_YK5D0W63vlWS8pNXaC_vAK7uMsb-XX3w=.717990e5-056e-4987-a5d0-d71e1db6456c@github.com>
 <9oErSGZO2hcusvCEEV2eJTgmev_v-5OJclGdyyLwPJg=.2f44899a-2a76-42c1-bde7-b180c5b991ef@github.com>
Message-ID: <e_AXIx4RQMxU3gMqz6vj1BE5J7RMC5LdyuY2QiHR6KE=.e8e30fb8-f9e1-47e9-abda-d05f93f52533@github.com>

On Tue, 28 Feb 2023 13:57:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Thanks @prrace for your inputs.
>> I dont think -fPIC is implied by -fpic. @erikj79  please clarify.
>> 
>> Difference between -fpic and -fPIC:
>> 1) With -fPIC we have unlimited storage capacity for global offset table and with -fpic on some platforms we have limitation on this size. For aarch64 it is 28k, but in case of x86 size of GOT is unlimited irrespective of -fPIC or -fpic. This is already captured.
>> 2) Also it looks like if we use -fpic option instead of -fPIC we may generate smaller/faster code as mentioned at http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html. Looks like in our case, 28k GOT size suffices and we are able to create smaller/faster code for libawt in case of aarch64. This inturn looks to be related to usage of -msmall-data or -mlarge-data flags. -fpic implies -msmall-data and -fPIC implies -mlarge-data while generating code for shared libraries. -msmall-data also talks about data being nearer and easily accessible compared to  -mlarge-data(https://man7.org/linux/man-pages/man1/gcc.1.html)
>> 
>> Also i can make this change specific to aarch64 since we are seeing its effect only on aarch64.
>
> I think you have read more about the differences between -fpic and -fPIC than I have, so nothing I can add here.
> 
> Making this option only on aarch64 seems like a reasonable idea if that's where we see the effect.

> I dont think -fPIC is implied by -fpic. @erikj79 please clarify.

That isn't what I said.
I said they they do very similar things, based on the references I read
with just a specific difference is that lower case "fpic" can be limited in size.

which is why I  wrote
>  So far as I can tell the -fpic are using just limits the size of the global offset table that -fPIC will generate.

My comment
> Since we had an unlimited offset table before, then -fpic won't change anything.

I was trying to point out that if your eval + fix is explained by saying we no longer
have "-fpic" then that's wrong. We never had -fpic.
We didn't change compiler options, but clearly performance changed


The man page you just linked does explain how the mechanism -fpic uses
which limits size could result in better performance

" When generating code for shared libraries, -fpic implies
           -msmall-data and -fPIC implies -mlarge-data."

"When -msmall-data is used,
           objects 8 bytes long or smaller are placed in a small data
           area (the ".sdata" and ".sbss" sections) and are accessed via
           16-bit relocations off of the $gp register."
 
So on some architectures it can be faster.

BUT since we were using -fPIC for a long time, I am not seeing how  you've
explained WHY we now need to explicitly use -fpic to get the performance back ?
In other words "we mysteriously lost performance, but I've found an option that helps".

So possibly, if you applied -fpic to the JDK before the regression it would get even faster ...

-------------

PR: https://git.openjdk.org/jdk/pull/12761


From serb at openjdk.org  Tue Feb 28 23:58:04 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Feb 2023 23:58:04 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v3]
In-Reply-To: <iQV2krpbZWIo9qMv7o9Hpa4BokiURJM2XX5OBzxBex8=.cd5fa1bf-5bdd-4d40-a636-a9e0b16a3837@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <iQV2krpbZWIo9qMv7o9Hpa4BokiURJM2XX5OBzxBex8=.cd5fa1bf-5bdd-4d40-a636-a9e0b16a3837@github.com>
Message-ID: <T1p4rkxace2Uaz5Wvomf0AtmF72jECF3VSvrqaCIvTU=.121b6add-b62f-4cb5-89cd-8f5bb820752b@github.com>

On Tue, 28 Feb 2023 06:55:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
>> 
>> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
>> 
>> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
>> 
>> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shift comment

When I mention that option in the JBS, I meant that we should take a look on how the methods in the library are "packed" since for some reason "-fpic" make some difference, probably we should use "static" more often or something like that. It is better to check what is the actual difference in the generated/packed code.

-------------

PR: https://git.openjdk.org/jdk/pull/12761


From 845158228 at qq.com  Tue Feb  7 03:35:59 2023
From: 845158228 at qq.com (=?utf-8?B?5b6Q5p2o?=)
Date: Tue, 07 Feb 2023 03:35:59 -0000
Subject: Build OpenJDK17 On Win10 error
Message-ID: <tencent_C74628A7FCD1EB80B97D8C4C055201F5EE05@qq.com>

Hellow:

  When i compile openjdk of version jdk-17-35 on windows 10, appear a trouble of follow, I can?t get useful information from the doc, who can help me shoot this trouble?

Thanks very much.

xsy at DESKTOP-QL6LMRE ~/openjdk/jdk-jdk-17-35
$  ./configure --with-toolchain-version=2017 --disable-warnings-as-errors
configure: Configuration created at Tue Feb  7 07:23:13 CST 2023.
checking for basename... /usr/bin/basename
checking for dirname... /usr/bin/dirname
checking for file... /usr/bin/file
checking for ldd... /usr/bin/ldd
checking for bash... /usr/bin/bash
checking for cat... /usr/bin/cat
checking for chmod... /usr/bin/chmod
checking for cp... /usr/bin/cp
checking for cut... /usr/bin/cut
checking for date... /usr/bin/date
checking for gdiff... [not found]
checking for diff... /usr/bin/diff
checking for echo... echo [builtin]
checking for expr... /usr/bin/expr
checking for find... /usr/bin/find
checking for gunzip... /usr/bin/gunzip
checking for pigz... [not found]
checking for gzip... /usr/bin/gzip
checking for head... /usr/bin/head
checking for ln... /usr/bin/ln
checking for ls... /usr/bin/ls
checking for gmkdir... [not found]
checking for mkdir... /usr/bin/mkdir
checking for mktemp... /usr/bin/mktemp
checking for mv... /usr/bin/mv
checking for gawk... /usr/bin/gawk
checking for printf... printf [builtin]
checking for rm... /usr/bin/rm
checking for rmdir... /usr/bin/rmdir
checking for sh... /usr/bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... [not found]
checking for tar... /usr/bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /usr/bin/uname
checking for wc... /usr/bin/wc
checking for xargs... /usr/bin/xargs
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for a sed that does not truncate output... /usr/bin/sed
checking for df... /usr/bin/df
checking for nice... /usr/bin/nice
checking for greadlink... [not found]
checking for readlink... /usr/bin/readlink
checking for cygpath... /usr/bin/cygpath
checking for lsb_release... [not found]
checking for cmd.exe... /cygdrive/c/Windows/system32/cmd.exe
checking for cmp... /usr/bin/cmp
checking for uniq... /usr/bin/uniq
checking build system type... x86_64-unknown-cygwin
checking host system type... x86_64-unknown-cygwin
checking target system type... x86_64-unknown-cygwin
checking openjdk-build os-cpu... windows-x86_64
checking openjdk-target os-cpu... windows-x86_64
checking compilation type... native
checking Windows environment type... cygwin
checking cygwin drive prefix... '/cygdrive'
checking cygwin root directory as Windows path... 'D:\cygwin'
checking cygwin temp directory... /tmp
checking cygwin release... 3.4.5-1.x86_64
checking cygwin version... 2023-01-19 19:09 UTC
checking Windows version... 10.0.19045.2486
checking what kind of 'find' is first on the PATH... unix style
checking for top-level directory... /home/xsy/openjdk/jdk-jdk-17-35
checking if custom source is suppressed (openjdk-only)... disabled, default
checking for --enable-debug... disabled, default
checking which debug level to use... release
checking which variants of the JVM to build... server
checking if absolute paths should be allowed in the build output... no, release build
checking for sysroot...
checking for toolchain path...
checking for extra path...
checking where to store configuration... in default location
checking what configuration name to use... windows-x86_64-server-release
checking for zypper... [not found]
checking for apt-get... [not found]
checking for yum... [not found]
checking for brew... [not found]
checking for port... [not found]
checking for pkgutil... [not found]
checking for pkgadd... [not found]
checking for pacman... [not found]
checking for pandoc... [not found]
checking for gmake... [not found]
checking for make... /usr/bin/make
configure: Testing potential make at /usr/bin/make, found using make in PATH
configure: Using GNU make at /usr/bin/make (version: GNU Make 4.4)
checking if make --output-sync is supported... yes
checking for output-sync value... none
checking if find supports -delete... yes
checking what type of tar was found... gnu
checking that grep (/usr/bin/grep) -Fx handles empty lines in the pattern list correctly... yes
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for greadelf... [not found]
checking for readelf... [not found]
checking for dot... [not found]
checking for hg... [not found]
checking for git... $FIXPATH /cygdrive/c/progra~1/git/cmd/git.exe
checking for stat... /usr/bin/stat
checking for time... time [builtin]
checking for flock... /usr/bin/flock
checking for dtrace... [not found]
checking for gpatch... [not found]
checking for patch... [not found]
checking bash version... 4.4.12
checking if bash supports pipefail... yes
checking if bash supports errexit (-e)... yes
checking for pkg-config... no
checking for default LOG value...
checking if packaged modules are kept... enabled, default
checking for version string... 17-internal+0-adhoc.xsy.jdk-jdk-17-35
configure: Found potential Boot JDK using JAVA_HOME
checking for Boot JDK... /cygdrive/d/devtools/jdk-17.0.6
checking Boot JDK version... java version "17.0.6" 2023-01-17 LTS Java(TM) SE Runtime Environment (build 17.0.6+9-LTS-190) Java HotSpot(TM) 64-Bit Server VM (build 17.0.6+9-LTS-190, mixed mode, sharing)
checking for java [Boot JDK]... $BOOT_JDK/bin/java
checking for javac [Boot JDK]... $BOOT_JDK/bin/javac
checking for javadoc [Boot JDK]... $BOOT_JDK/bin/javadoc
checking for jar [Boot JDK]... $BOOT_JDK/bin/jar
checking if Boot JDK is 32 or 64 bits... 64
checking for local Boot JDK Class Data Sharing (CDS)... yes, created
checking for Build JDK... yes, will use output dir
checking for docs-reference JDK... no, using interim javadoc for the docs-reference targets
checking if we should build headless-only (no GUI)... disabled, default
checking if linker should clean out unused code (linktime-gc)... disabled, default
checking for graphviz dot... no, cannot generate full docs
checking for pandoc... no, cannot generate full docs
checking for --enable-full-docs... disabled, from default 'auto'
checking for cacerts file... default
checking for --enable-unlimited-crypto... enabled, default
checking for jni library path... default
checking if static build is available... no
checking if static build is enabled... disabled, default
configure: Using default toolchain microsoft (Microsoft Visual Studio)
configure: Found Visual Studio installation at /cygdrive/d/micvs/2017/professional using well-known name
configure: Found Microsoft Visual Studio 2017
configure: Trying to extract Visual Studio environment variables for x86_64
configure: using /cygdrive/d/micvs/2017/professional/vc/auxiliary/build/vcvarsx86_amd64.bat
configure: Setting extracted environment variables for x86_64
fixpath: failure: Path '/cygdrive/d/micvs/2017/professional/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space
fixpath: failure: Path '/cygdrive/d/micvs/2017/professional/team tools/performance tools' contains space
checking that Visual Studio variables have been correctly extracted... ok
checking for cl... $FIXPATH /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe
checking resolved symbolic links for CC... no symlink
configure: Using microsoft C compiler version 19.10.25027 [Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25027 for x64]
checking whether the C compiler works... yes
checking for C compiler default output file name... conftest.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... obj
checking whether the compiler supports GNU C... no
checking whether /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/fixpath exec /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe accepts -g... yes
checking for /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/fixpath exec /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe option to enable C11 features... unsupported
checking for /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/fixpath exec /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe option to enable C99 features... unsupported
checking for /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/fixpath exec /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe option to enable C89 features... unsupported
checking for cl... $FIXPATH /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe
checking resolved symbolic links for CXX... no symlink
configure: Using microsoft C++ compiler version 19.10.25027 [Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25027 for x64]
checking whether the compiler supports GNU C++... no
checking whether /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/fixpath exec /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe accepts -g... yes
checking for /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/fixpath exec /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe option to enable C++11 features... none needed
checking how to run the C preprocessor... /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/fixpath exec /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe -E
checking how to run the C++ preprocessor... /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/fixpath exec /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe -E
checking for link... $FIXPATH /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/link.exe
checking if the found link.exe is actually the Visual Studio linker... yes
configure: Using microsoft linker version 14.10.25027.0 [Microsoft (R) Incremental Linker Version 14.10.25027.0]
checking for ml64... $FIXPATH /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/ml64.exe
checking for lib... $FIXPATH /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/lib.exe
checking for mt... $FIXPATH /cygdrive/c/progra~2/wi3cf2~1/10/bin/x86/mt.exe
checking for rc... $FIXPATH /cygdrive/c/progra~2/wi3cf2~1/10/bin/x86/rc.exe
checking for dumpbin... $FIXPATH /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/dumpbin.exe
checking for gobjdump... [not found]
checking for objdump... [not found]
checking for jtreg... [not found]
checking for jtreg test harness... no, not found
checking for jmh (Java Microbenchmark Harness)... no, disabled
checking for jib... no
checking if CC supports "-m64"... yes
checking if CXX supports "-m64"... yes
checking if both CC and CXX support "-m64"... yes
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... no
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... no
checking for stdio.h... (cached) yes
checking size of int *... 8
checking for target address size... 64 bits
checking whether byte ordering is bigendian... no
checking what source date to use... determined at build time, from 'updated'
checking for --enable-reproducible-build... enabled, default
checking for --enable-warnings-as-errors... disabled, from command line
checking if CC supports "-experimental:deterministic -wd5048"... yes
checking if CXX supports "-experimental:deterministic -wd5048"... yes
checking if both CC and CXX support "-experimental:deterministic -wd5048"... yes
checking if CC supports "-pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s           -pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s"... yes
checking if CXX supports "-pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s           -pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s"... yes
checking if both CC and CXX support "-pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s           -pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s"... yes
checking how to prevent absolute paths in output... using compiler options
checking if BUILD_CC supports "-experimental:deterministic -wd5048"... yes
checking if BUILD_CXX supports "-experimental:deterministic -wd5048"... yes
checking if both BUILD_CC and BUILD_CXX support "-experimental:deterministic -wd5048"... yes
checking if BUILD_CC supports "-pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s           -pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s"... yes
checking if BUILD_CXX supports "-pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s           -pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s"... yes
checking if both BUILD_CC and BUILD_CXX support "-pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s           -pathmap:D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35=s"... yes
checking how to prevent absolute paths in output... using compiler options
checking what type of native debug symbols to use... external
checking if we should add external native debug symbols to the shipped bundles... no
checking if native coverage is available... no
checking for --enable-native-coverage... disabled, default
checking if AddressSanitizer (asan) is available... no
checking for --enable-asan... disabled, default
configure: Found vcruntime140.dll at /cygdrive/d/devtools/jdk-17.0.6/bin/vcruntime140.dll using well-known location in Boot JDK
checking found vcruntime140.dll architecture... ok
checking for vcruntime140.dll... /cygdrive/d/devtools/jdk-17.0.6/bin/vcruntime140.dll
configure: Found msvcp140.dll at /cygdrive/d/devtools/jdk-17.0.6/bin/msvcp140.dll using well-known location in Boot JDK
checking found msvcp140.dll architecture... ok
checking for msvcp140.dll... /cygdrive/d/devtools/jdk-17.0.6/bin/msvcp140.dll
checking for UCRT DLL dir... /cygdrive/c/progra~2/wi3cf2~1/10//redist/ucrt/dlls/x64
Using freetype: bundled
checking for --enable-libffi-bundling... disabled, default
checking for which libjpeg to use... bundled
checking for which giflib to use... bundled
checking for PNG... checking for which libpng to use... bundled
checking for compress in -lz... no
checking for which zlib to use... bundled
checking for which lcms to use... bundled
checking for which harfbuzz to use... bundled
checking for dlopen in -ldl... no
checking for JVM features enabled by the user... none
checking for JVM features disabled by the user... none
checking if platform is supported by CDS... yes
checking if JVM feature 'cds' is available... yes
checking for dtrace tool... no
checking for sys/sdt.h... no
configure: Cannot enable dtrace with missing dependencies. See above.
checking if JVM feature 'dtrace' is available... no
checking if platform is supported by JFR... yes
checking if JVM feature 'jfr' is available... yes
checking if platform is supported by JVMCI... yes
checking if JVM feature 'jvmci' is available... yes
checking if platform is supported by Shenandoah... yes
checking if JVM feature 'shenandoahgc' is available... yes
checking if static-build is enabled in configure... no, use --enable-static-build to enable static build.
checking if JVM feature 'static-build' is available... no
checking if platform is supported by ZGC... yes
checking if Windows APIs required for ZGC is present... no, missing required APIs
checking if JVM feature 'zgc' is available... no
checking JVM features to use for variant 'server'... 'cds compiler1 compiler2 epsilongc g1gc jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs'
checking if the jtreg failure handler is available... no (jtreg not present)
checking if the jtreg failure handler should be built... disabled, from default 'auto'
checking if the CDS classlist generation should be enabled... enabled, from default 'auto'
checking if any translations should be excluded... no
checking if static man pages should be copied... enabled, default
checking if CDS archive is available... yes
checking if a default CDS archive should be generated... enabled, from default 'auto'
checking if CDS archive is available... yes
checking if compatible cds region alignment enabled... disabled, default
checking for number of cores... 8
checking for memory size... 12171 MB
checking for appropriate number of jobs to run in parallel... 8
checking whether to use javac server... enabled, default
checking flags for boot jdk java command ...  -Duser.language=en -Duser.country=US  -XX:+UnlockDiagnosticVMOptions -XX:-VerifySharedSpaces -XX:SharedArchiveFile=/home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/configure-support/classe
checking flags for boot jdk java command for big workloads...  -Xms64M -Xmx1600M
checking flags for bootcycle boot jdk java command for big workloads... -Xms64M -Xmx1600M
checking flags for boot jdk java command for small workloads...  -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1
checking for --enable-icecc... disabled, default
checking if precompiled headers are available... yes
checking for --enable-precompiled-headers... enabled, from default 'auto'
checking for ccache... [not found]
checking if ccache is available... no, not supported for toolchain type microsoft
checking if ccache is enabled... disabled, default
checking if build directory is on local disk... yes
configure: creating /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/configure-support/config.status
config.status: creating /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/spec.gmk
config.status: creating /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/bootcycle-spec.gmk
config.status: creating /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/buildjdk-spec.gmk
config.status: creating /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/compare.sh
config.status: creating /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/Makefile

====================================================
The existing configuration has been successfully updated in
/home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release
using configure arguments '--with-toolchain-version=2017 --disable-warnings-as-errors'.

Configuration summary:
* Name:           windows-x86_64-server-release
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'cds compiler1 compiler2 epsilongc g1gc jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs'
* OpenJDK target: OS: windows, CPU architecture: x86, address length: 64
* Version string: 17-internal+0-adhoc.xsy.jdk-jdk-17-35 (17-internal)

Tools summary:
* Environment:    cygwin version 3.4.5-1.x86_64, 2023-01-19 19:09 UTC; windows version 10.0.19045.2486; prefix "/cygdrive"; root "D:\cygwin"
* Boot JDK:       java version "17.0.6" 2023-01-17 LTS Java(TM) SE Runtime Environment (build 17.0.6+9-LTS-190) Java HotSpot(TM) 64-Bit Server VM (build 17.0.6+9-LTS-190, mixed mode, sharing) (at /cygdrive/d/devtools/jdk-17.0.6)
* Toolchain:      microsoft (Microsoft Visual Studio 2017)
* C Compiler:     Version 19.10.25027 (at /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe)
* C++ Compiler:   Version 19.10.25027 (at /cygdrive/d/micvs/2017/professional/vc/tools/msvc/14.10.25017/bin/hostx86/x64/cl.exe)

Build performance summary:
* Cores to use:   8
* Memory limit:   12171 MB

WARNING: The result of this configuration has overridden an older
configuration. You *should* run 'make clean' to make sure you get a
proper build. Failure to do so might result in strange build problems.


xsy at DESKTOP-QL6LMRE ~/openjdk/jdk-jdk-17-35
$ make images
Building target 'images' in configuration 'windows-x86_64-server-release'
Compiling 1 files for BUILD_TOOLS_HOTSPOT
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Warning: No SCM configuration present and no .src-rev
Parsing 2 properties into enum-like class for jdk.compiler
Compiling 13 properties into resource bundles for jdk.javadoc
Compiling 16 properties into resource bundles for jdk.compiler
Compiling 7 properties into resource bundles for jdk.jshell
Compiling 12 properties into resource bundles for jdk.jdeps
Compiling 127 files for BUILD_java.compiler.interim
Compiling 402 files for BUILD_jdk.compiler.interim
Compiling 229 files for BUILD_jdk.javadoc.interim
Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s)
Compiling 2 files for BUILD_JVMTI_TOOLS
Creating support/modules_libs/java.base/server/jvm.dll from 985 file(s)
cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
cl : Command line warning D9002 : ignoring unknown option '-experimental:deterministic'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(127): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(127): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(128): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(128): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(136): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(136): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(137): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(137): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(117): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(117): error C3431: 'OptionType': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(152): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(157): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(161): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(173): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(177): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(181): error C3431: 'OptionType': a scoped enumeration cannot be redeclared as an unscoped enumeration
make[3]: *** [lib/CompileJvm.gmk:143: /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] Error 1
make[2]: *** [make/Main.gmk:252: hotspot-server-libs] Error 2
make[2]: *** Waiting for unfinished jobs....

ERROR: Build failed for target 'images' in configuration 'windows-x86_64-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:
BUILD_LIBJVM_pch.cpp
cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
cl : Command line warning D9002 : ignoring unknown option '-experimental:deterministic'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(127): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(127): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(128): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(128): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(136): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(136): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(137): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(137): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
   ... (rest of output omitted)

* All command lines available in /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See doc/building.html#troubleshooting for assistance.

make[1]: *** [/home/xsy/openjdk/jdk-jdk-17-35/make/Init.gmk:315: main] Error 2
make: *** [/home/xsy/openjdk/jdk-jdk-17-35/make/Init.gmk:186: images] Error 2


xsy at DESKTOP-QL6LMRE ~/openjdk/jdk-jdk-17-35
$ grep -r "cygwinhomexsyopenjdkjdk" ./*
./build/windows-x86_64-server-release/build.log:cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
./build/windows-x86_64-server-release/build.log:cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
./build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj.log:cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
./build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj.log:cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
./build/windows-x86_64-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj.log:cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
./build/windows-x86_64-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj.log:cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'

xsy at DESKTOP-QL6LMRE ~/openjdk/jdk-jdk-17-35
$ ^C

xsy at DESKTOP-QL6LMRE ~/openjdk/jdk-jdk-17-35
$ cd build/windows-x86_64-server-release/

xsy at DESKTOP-QL6LMRE ~/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release
$ ls
Makefile  bootcycle-spec.gmk  build.log  build.log.old  buildjdk-spec.gmk  buildtools  compare.sh  configure-support  configure.log  configure.log.old  fixpath  hotspot  jdk  make-support  spec.gmk  support

xsy at DESKTOP-QL6LMRE ~/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release
$ cat build.log
Building target 'images' in configuration 'windows-x86_64-server-release'
Compiling 1 files for BUILD_TOOLS_HOTSPOT
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Warning: No SCM configuration present and no .src-rev
Parsing 2 properties into enum-like class for jdk.compiler
Compiling 13 properties into resource bundles for jdk.javadoc
Compiling 16 properties into resource bundles for jdk.compiler
Compiling 7 properties into resource bundles for jdk.jshell
Compiling 12 properties into resource bundles for jdk.jdeps
Compiling 127 files for BUILD_java.compiler.interim
Compiling 402 files for BUILD_jdk.compiler.interim
Compiling 229 files for BUILD_jdk.javadoc.interim
Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s)
Compiling 2 files for BUILD_JVMTI_TOOLS
Creating support/modules_libs/java.base/server/jvm.dll from 985 file(s)
cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
cl : Command line warning D9002 : ignoring unknown option '-pathmap:D:cygwinhomexsyopenjdkjdk-jdk-17-35=s'
cl : Command line warning D9002 : ignoring unknown option '-experimental:deterministic'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(127): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(127): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(128): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(128): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(136): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(136): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(137): error C2672: 'PrimitiveConversions::cast': no matching overloaded function found
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(137): error C2783: 'To PrimitiveConversions::cast(From)': could not deduce template argument for '__formal'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\metaprogramming/primitiveConversions.hpp(63): note: see declaration of 'PrimitiveConversions::cast'
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(117): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(117): error C3431: 'OptionType': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(152): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(157): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(161): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(173): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(177): error C3431: 'CompileCommand': a scoped enumeration cannot be redeclared as an unscoped enumeration
D:\cygwin\home\xsy\openjdk\jdk-jdk-17-35\src\hotspot\share\compiler/compilerOracle.hpp(181): error C3431: 'OptionType': a scoped enumeration cannot be redeclared as an unscoped enumeration
make[3]: *** [lib/CompileJvm.gmk:143: /home/xsy/openjdk/jdk-jdk-17-35/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj] Error 1
make[2]: *** [make/Main.gmk:252: hotspot-server-libs] Error 2
make[2]: *** Waiting for unfinished jobs....

ERROR: Build failed for target 'images' in configuration 'windows-x86_64-server-release' (exit code 2)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20230207/b9a19e6f/attachment.htm>