From trebari at openjdk.java.net  Mon Mar  1 09:42:53 2021
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Mon, 1 Mar 2021 09:42:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262497: Delete unused utility methods in
 ICC_Profile class
In-Reply-To: <mVXpRxj2UdEmRl-V29GW_D23RX2WEtp-BkunWXCRLis=.208ab2e3-e867-4f57-84c9-193ecc082ce8@github.com>
References: <mVXpRxj2UdEmRl-V29GW_D23RX2WEtp-BkunWXCRLis=.208ab2e3-e867-4f57-84c9-193ecc082ce8@github.com>
Message-ID: <B4zrQZfHoTgkUJKkQIxfumjw_t4-FHXM7OYOwp6FoJQ=.cdf9469c-b206-4d59-b51a-a960bf943903@github.com>

On Sun, 28 Feb 2021 04:59:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> A few utility methods in the ICC_Profile class are unused since 1997, I think we can delete them.

Marked as reviewed by trebari (Committer).

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

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

From aph at openjdk.java.net  Mon Mar  1 10:33:59 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 10:33:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v21]
In-Reply-To: <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
Message-ID: <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>

On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>  - Minor fixes

src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:

> 60: 
> 61: #if defined(__APPLE__) || defined(_WIN64)
> 62: #define R18_RESERVED

#define R18_RESERVED true```

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

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

From aph at openjdk.java.net  Mon Mar  1 11:09:56 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v10]
In-Reply-To: <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
Message-ID: <olzq5_KwRPyDE2-CoFcqPX9aR0wix5WogLrCo1bgD2I=.ceb47235-e205-4729-b59f-ec9b7033ebe6@github.com>

On Thu, 4 Feb 2021 23:01:52 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 652:
> 
>> 650: 
>> 651: void os::setup_fpu() {
>> 652: }
> 
> Is there really nothing to do here, or does still need to be implemented? A clarification comment here would help/.

There is really nothing to do here.

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 198:
> 
>> 196: 
>> 197: NOINLINE frame os::current_frame() {
>> 198:   intptr_t *fp = *(intptr_t **)__builtin_frame_address(0);
> 
> In the bsd_x86 counter part we initialize `fp` to `_get_previous_fp()` - do we need to implement it on aarch64 as well (and using address 0 is just a temp workaround) or is it doing the right thing here?

(0)``` looks right to me.

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 291:
> 
>> 289:         bool is_unsafe_arraycopy = (thread->doing_unsafe_access() && UnsafeCopyMemory::contains_pc(pc));
>> 290:         if ((nm != NULL && nm->has_unsafe_access()) || is_unsafe_arraycopy) {
>> 291:           address next_pc = pc + NativeCall::instruction_size;
> 
> Replace
> 
> address next_pc = pc + NativeCall::instruction_size;
> 
> with
> 
> address next_pc = Assembler::locate_next_instruction(pc);
> 
> there is at least one other place that needs it.

Why is this change needed? AFAICS ```locate_next_instruction()``` is an x86 thing for variable-length instructions, and no other port uses it.

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

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

From aph at openjdk.java.net  Mon Mar  1 11:09:55 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v21]
In-Reply-To: <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
Message-ID: <5l97Ac1W-JbLiCBJMoWut-c-RZEPN6wBHABym2nHeRE=.6d060249-e315-486b-a0ab-1992de6f54d5@github.com>

On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>  - Minor fixes

Thanks. With this, I think we're done.

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

Changes requested by aph (Reviewer).

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

From aph at openjdk.java.net  Mon Mar  1 11:09:57 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@github.com>
 <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>
Message-ID: <cJ0oJULLMQqSzHz-xHWMiJrivyH59QxUI2UQTN0PrdE=.77b688e8-52f1-4207-be64-3393922ecdb6@github.com>

On Fri, 5 Feb 2021 17:20:55 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93:
>> 
>>> 91:     CPU_MARVELL   = 'V',
>>> 92:     CPU_INTEL     = 'i',
>>> 93:     CPU_APPLE     = 'a',
>> 
>> The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile` has 8538 pages, can we be more specific and point to the particular section of the document where the CPU codes are defined?
>
> They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not there, but "Arm can assign codes that are not published in this manual. All values not assigned by Arm are reserved and must not be used.". I assume the value was obtained by digging around https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62

Anton, this paragraph looks like an excellent comment.

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

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

From aph at openjdk.java.net  Mon Mar  1 11:09:58 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v10]
In-Reply-To: <hwBUUi7NHd91Sc9fpH0hTqLXvp2H8ax9-YGqCo4fC2g=.bb995b11-1795-42e8-8a9a-d95406ed8513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com>
 <hwBUUi7NHd91Sc9fpH0hTqLXvp2H8ax9-YGqCo4fC2g=.bb995b11-1795-42e8-8a9a-d95406ed8513@github.com>
Message-ID: <wl_FMfr8IuW0pM6APkV36vyWvmy4bsdaoSgWHA-yMmo=.d4ecb78c-e199-4e1c-9215-d68e2d25bc15@github.com>

On Fri, 12 Feb 2021 11:42:59 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194:
>> 
>>> 192: // may get turned off by -fomit-frame-pointer.
>>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>>> 194:   return frame(fr->link(), fr->link(), fr->sender_pc());
>> 
>> Why is it
>> 
>> return frame(fr->link(), fr->link(), fr->sender_pc());
>> 
>> and not 
>> 
>> return frame(fr->sender_sp(), fr->link(), fr->sender_pc());
>> 
>> like in the bsd-x86 counter part?
>
> bsd_aarcb64 was based on linux_aarch64, with addition of bsd-specific things from bsd_x86
> You think  the bsd-x86 way is better here ?

There's no point copying x86. We don't have any way to know what the sender's SP was in a C frame without using unwind info. I think this is just used when trying to print the stack in a crash dump.

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

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

From aghaisas at openjdk.java.net  Mon Mar  1 11:17:39 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 1 Mar 2021 11:17:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

Ajit Ghaisas 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 36 additional commits since the last revision:

 - Lanai PR#206 - 8262729 - aghaisas
 - Lanai PR#205 - 8262496 - avu
 - Lanai PR#203 - 8262313 - jdv
 - Lanai PR#202 - 8262293 - avu
 - Lanai PR#201 - 8261891 - avu
 - Lanai PR#200 - 8262115 - aghaisas
 - Merge branch 'master' into 8260931_lanai_JEP_branch
 - Lanai PR#199 - 8262091 - aghaisas
 - Lanai PR#198 - 8261646 - avu
 - Lanai PR#197 - 8261960 - jdv
 - ... and 26 more: https://git.openjdk.java.net/jdk/compare/dd205a58...5cb1fd91

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/614be056..5cb1fd91

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=08-09

  Stats: 14064 lines in 640 files changed: 7890 ins; 3094 del; 3080 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

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

From kizune at openjdk.java.net  Mon Mar  1 11:33:46 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 1 Mar 2021 11:33:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262497: Delete unused utility methods in
 ICC_Profile class
In-Reply-To: <mVXpRxj2UdEmRl-V29GW_D23RX2WEtp-BkunWXCRLis=.208ab2e3-e867-4f57-84c9-193ecc082ce8@github.com>
References: <mVXpRxj2UdEmRl-V29GW_D23RX2WEtp-BkunWXCRLis=.208ab2e3-e867-4f57-84c9-193ecc082ce8@github.com>
Message-ID: <-NnRRT1bOSmavf24LclPhtMbLgKDkJo9yCKtKcqE0jY=.e309576b-0f44-498f-8b46-91eb23b09ef1@github.com>

On Sun, 28 Feb 2021 04:59:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> A few utility methods in the ICC_Profile class are unused since 1997, I think we can delete them.

Marked as reviewed by kizune (Reviewer).

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

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

From serb at openjdk.java.net  Mon Mar  1 19:34:39 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 1 Mar 2021 19:34:39 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8262497: Delete unused utility methods
 in ICC_Profile class
In-Reply-To: <mVXpRxj2UdEmRl-V29GW_D23RX2WEtp-BkunWXCRLis=.208ab2e3-e867-4f57-84c9-193ecc082ce8@github.com>
References: <mVXpRxj2UdEmRl-V29GW_D23RX2WEtp-BkunWXCRLis=.208ab2e3-e867-4f57-84c9-193ecc082ce8@github.com>
Message-ID: <bjMQnWfTo7TBUusRGPSQWiyxrXcDachq3610TfknsMA=.ae65aee0-2d72-41e3-a5fb-9fa2973f9698@github.com>

On Sun, 28 Feb 2021 04:59:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> A few utility methods in the ICC_Profile class are unused since 1997, I think we can delete them.

This pull request has now been integrated.

Changeset: 682e1202
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/682e1202
Stats:     53 lines in 1 file changed: 0 ins; 51 del; 2 mod

8262497: Delete unused utility methods in ICC_Profile class

Reviewed-by: azvegint, pbansal, trebari, kizune

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

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

From akozlov at openjdk.java.net  Tue Mar  2 07:48:33 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 07:48:33 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v22]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <v5pZx2-cL7w14ww7AUj0-aM3H0WLtdE9KQOMcmz3oXM=.de608aec-285e-420c-a0bd-87ff2621366a@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Update comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/663cb4a1..e42b82db

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=20-21

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

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

From akozlov at openjdk.java.net  Tue Mar  2 07:48:34 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 07:48:34 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <cJ0oJULLMQqSzHz-xHWMiJrivyH59QxUI2UQTN0PrdE=.77b688e8-52f1-4207-be64-3393922ecdb6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@github.com>
 <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>
 <cJ0oJULLMQqSzHz-xHWMiJrivyH59QxUI2UQTN0PrdE=.77b688e8-52f1-4207-be64-3393922ecdb6@github.com>
Message-ID: <M-kUXnyeRkWZF8-CcGTlKqCGerC7BpZ4KUFKbPEm9Dw=.0692eac6-4803-4110-b46b-0658cd0b10cd@github.com>

On Mon, 1 Mar 2021 10:46:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not there, but "Arm can assign codes that are not published in this manual. All values not assigned by Arm are reserved and must not be used.". I assume the value was obtained by digging around https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62
>
> Anton, this paragraph looks like an excellent comment.

Thanks, I've added the comment.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 07:48:36 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 07:48:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <MF1iA9imUPiz__P2Xgl06D6uqX6m3yi5_LkRtVy0yYA=.985a8d8e-d585-4ca1-8c27-3752dc4f297a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <MF1iA9imUPiz__P2Xgl06D6uqX6m3yi5_LkRtVy0yYA=.985a8d8e-d585-4ca1-8c27-3752dc4f297a@github.com>
Message-ID: <NMDh28nN07b-L4FvOo_lZSVr6WTbMjQtwXB4uOpbRgU=.e025620b-bb0e-4f81-aea4-7c023a268161@github.com>

On Mon, 15 Feb 2021 17:59:54 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810:
>> 
>>> 808: #ifdef __APPLE__
>>> 809:           // Less-than word types are stored one after another.
>>> 810:           // The code unable to handle this, bailout.
>> 
>> Perhaps:  // The code is unable to handle this so bailout.
>
> Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered

I've fixed the spelling. Sorry for it to take so long :(

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195:
>> 
>>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>>> 194:   return frame(fr->link(), fr->link(), fr->sender_pc());
>>> 195: }
>> 
>> Is this file going to be built by GCC or just macOS compilers?
>
> there is no support for compiling java with gcc on macos since about jdk11, only clang.
> considering this and the absence of gcc for macos_m1, the answer is - just macOS compilers.

I've fixed the comment. Now it states `JVM compiled with -fno-omit-frame-pointer, so RFP is saved on the stack.`

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

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

From akozlov at openjdk.java.net  Tue Mar  2 08:06:49 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 08:06:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <gYlruHfPt3n_2sFsFzadoB-H9J1sZJQsspB9AjKeO2o=.ca9e5f03-7181-42cb-b2d9-4f3490f05235@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WI3MFWpvxNdYp4WRkhkagyWSmnIIAfvYWl3nS8AW_Y0=.b09073dd-cec3-4dbd-88c4-974d46b01737@github.com>
 <gYlruHfPt3n_2sFsFzadoB-H9J1sZJQsspB9AjKeO2o=.ca9e5f03-7181-42cb-b2d9-4f3490f05235@github.com>
Message-ID: <UNXam2gyH9Z3bgNClVHc956LquoEu1KkZ-89DQpu4ZE=.5a71445d-0dbd-4ae9-8fe8-0e279cb7fc61@github.com>

On Fri, 12 Feb 2021 12:40:09 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> only macos comiplers
>
> The comment is also wrong for glibc: The AArch64 ABI requires a 64 KiB guard region independently of page size, otherwise `-fstack-clash-protection` is not reliable.

Thanks, I deleted the comment. It describes implementation distinguishing initial and regular thread http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/548cb3b7b713#l12.7. I'm not sure why the comment was preserved for the bsd_x86, but I don't think it makes sense here.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 08:14:46 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 08:14:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>
Message-ID: <Ei8n5Xqt_Usrtyz-M4AudO6fuOV30FTSG6BCpNXUa2w=.fe6928be-256e-4448-b094-1f7c869e4b26@github.com>

On Fri, 12 Feb 2021 13:32:52 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486:
>> 
>>> 484:         }
>>> 485:       }
>>> 486:     }
>> 
>> This appears to be a mix for Mavericks (10.9) and 10.12
>> work arounds. Is this code needed by this project?
>
> I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround
> @gerard-ziemski, 8020753 was originally your fix, do you know if it still needed on intel-mac ?

The x86_bsd still carries the workaround https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745. It's worth having macos ports to be aligned by features. I would propose to have this workaround for now, and decide on it later for macos/x86 and macos/aarch64 at once. Sorry for chiming in so late.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 09:02:10 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 09:02:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
Message-ID: <u7KDYpBsS8hE4DIlr86x1XP2jNk2evuzajQr66XXjYI=.e7caf1a7-c841-43aa-95dc-e8b96df309da@github.com>

On Tue, 2 Feb 2021 22:18:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   support macos_aarch64 in hsdis
>
> src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp line 43:
> 
>> 41:   assert(Thread::current() == this, "caller must be current thread");
>> 42:   return pd_get_top_frame(fr_addr, ucontext, isInJava);
>> 43: }
> 
> Is AsyncGetCallTrace() being supported by this port?

I assume answer to be yes (I have a little experience with AsyncGetCallTrace). This code is identical to one in bsd/x86 and linux/aarch64. After few changes in the build system, I got jtreg/serviceability/AsyncGetCallTrace test compiled and passed. I've filed JDK-8262839 to enable the test.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 09:36:51 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 09:36:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
Message-ID: <0dfmwagb4EGbnQnZIzpQ_36c9_fpvvebrgnKDW4E9Ps=.e54e9fb2-7500-40d8-8202-ce4903fd106f@github.com>

On Tue, 2 Feb 2021 22:47:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   support macos_aarch64 in hsdis
>
> src/hotspot/share/prims/nativeEntryPoint.cpp line 45:
> 
>> 43:   guarantee(status == JNI_OK && !env->ExceptionOccurred(),
>> 44:             "register jdk.internal.invoke.NativeEntryPoint natives");
>> 45: JNI_END
> 
> I thought that jcheck caught a missing new-line?

It seems it did not https://github.com/openjdk/jdk/commit/0fb31dbf3a2adc0f7fb2f9924083908724dcde5a#diff-f39cd3f794a337734adf30863f702725ee04182fee2345b2669e59ebed17a2ccR44. Anyway I reverted this change as it is the only change in the file, thanks.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 11:07:56 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 11:07:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
Message-ID: <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>

On Tue, 2 Feb 2021 23:10:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> For platform files that were copied from other ports to this port, if the file wasn't
> changed I presume the copyright years are left alone. If the file required changes
> for this port, I expect the year to be updated to 2021. How are you verifying that
> these copyright years are being properly managed on the new files?

There are no exact copies, based on
git -c diff.renameLimit=10000000 diff --find-copies-harder -C75% --name-status upstream/master...

So every file changed in the branch potentially needs the copyright update. All file diffs are not trivial, IMHO.

I'll run the copyright update after we fix a few remaining issues with the PR, to avoid updating copyright and changing/reverting the actual content.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 14:34:51 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 14:34:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v10]
In-Reply-To: <hEaFWHE_iOfvoT79PO1tsOkG0IVniyDakQlyH3_t70s=.a0083425-ef18-413b-be61-bfaa1eea8452@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <hEaFWHE_iOfvoT79PO1tsOkG0IVniyDakQlyH3_t70s=.a0083425-ef18-413b-be61-bfaa1eea8452@github.com>
Message-ID: <YYxKFpSFJVHj9FIQNUngREmO7aBwrmRWXrx5XIfeiEE=.b59b60c7-435b-4884-9f06-1c3b7c868d84@github.com>

On Thu, 4 Feb 2021 22:15:47 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 322:
> 
>> 320: #ifdef __APPLE__
>> 321:       } else if (sig == SIGFPE && info->si_code == FPE_NOOP) {
>> 322:         Unimplemented();
> 
> Is there a follow up issue for this?

Thanks, this is a leftover from the development phase, it will be removed. In macos/x86, this looks like a workaround. We've never met with this condition and it looks recent darwin kernel should correctly report the cause in si_code: https://github.com/apple/darwin-xnu/blob/33eb9835cd948dbbcdd8741aa52457cbe507c765/bsd/dev/arm/unix_signal.c#L436.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 20:32:49 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 20:32:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v10]
In-Reply-To: <9bn80xM9g41OytCtH71-krOZtAgy27TbvTFJHmfmKrE=.e9d223d5-2922-4891-8f45-ee039d88ced6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <9bn80xM9g41OytCtH71-krOZtAgy27TbvTFJHmfmKrE=.e9d223d5-2922-4891-8f45-ee039d88ced6@github.com>
Message-ID: <FqG48k4wPLWnjZX7DO2Vi9utptmRaSSLKZvAFkXJVuA=.50cf018d-194a-4149-82b3-bcf6ce6aa8fd@github.com>

On Thu, 4 Feb 2021 22:34:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 237:
> 
>> 235:       os::Posix::ucontext_set_pc(uc, StubRoutines::continuation_for_safefetch_fault(pc));
>> 236:       return true;
>> 237:     }
> 
> Isn't this case already handled by `JVM_HANDLE_XXX_SIGNAL()` ? Why do we need it here again?

Good point, thanks. We are missing a few fixes in os_cpu/bsd_aarch64. This was moved out recently. I'm going to align bsd_aarch64 with the rest of platforms.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 21:19:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 21:19:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v23]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with five additional commits since the last revision:

 - Fix after JDK-8259539, partially revert preconditions
 - JDK-8260471: bsd_aarch64 part
 - JDK-8259539: bsd_aarch64 part
 - JDK-8257828: bsd_aarch64 part
 - Cleanup os_bsd_aarch64 signal handling

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/e42b82db..4c37f068

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=21-22

  Stats: 31 lines in 1 file changed: 15 ins; 11 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From akozlov at openjdk.java.net  Tue Mar  2 21:19:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 21:19:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v10]
In-Reply-To: <-PhzrEcgREcbXuZ5GrxAfVa6Uwil9YoOkZULt1154rw=.9689a79e-cf61-4f79-9b36-a3295fecab7b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <i9UArB35vpHowW6HbtTkKLQX-wwfSx1dg1NKLHIRdGs=.5e08a151-8ad3-46cc-b006-34d750410c47@github.com>
 <-PhzrEcgREcbXuZ5GrxAfVa6Uwil9YoOkZULt1154rw=.9689a79e-cf61-4f79-9b36-a3295fecab7b@github.com>
Message-ID: <XOowePO_JQ-AQ342Gtf3w3J8nrin2YPdlj0ZP6gwYJM=.2884d345-3eab-4ba6-85f8-fde1d011df49@github.com>

On Fri, 12 Feb 2021 15:21:06 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302:
>> 
>>> 300:         const uint64_t *detail_msg_ptr
>>> 301:           = (uint64_t*)(pc + NativeInstruction::instruction_size);
>>> 302:         const char *detail_msg = (const char *)*detail_msg_ptr;
>> 
>> Where is `detail_msg` used?
>
> Came from linux_arm64. was used in os_linux_aarch64.cpp on line 246 in report_and_die
> But became unused on bsd_arm64. I agree this needs to be removed

It seems we have merged master branch before JDK-8259539 was integrated. It brings back use of detail_msg. I reverted details_msg as well its following use.

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

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

From akozlov at openjdk.java.net  Tue Mar  2 21:29:52 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 21:29:52 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v10]
In-Reply-To: <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
Message-ID: <k5nnBgnSMPy-3Zk3rnTAsmrFgMlO08wb_4wpfOYg4SM=.cf972a76-c5c6-4428-9574-66120fa79594@github.com>

On Thu, 4 Feb 2021 22:58:39 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 420:
> 
>> 418: size_t os::Posix::_compiler_thread_min_stack_allowed = 72 * K;
>> 419: size_t os::Posix::_java_thread_min_stack_allowed = 72 * K;
>> 420: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 72 * K;
> 
> Those are slightly larger than their x86_64 counter parts. Are they conservative/aggressive values? How did we arrive at those?

These values were copied from linux_aarch64. The motivation is that clang on macos/aarch64 will likely to produce stack frames for C++ functions similar to frames generates by gcc on linux/aarch64. And sizes of java stack frames should not change.

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

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

From dholmes at openjdk.java.net  Tue Mar  2 23:25:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 2 Mar 2021 23:25:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v23]
In-Reply-To: <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
Message-ID: <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>

On Tue, 2 Mar 2021 21:19:18 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Fix after JDK-8259539, partially revert preconditions
>  - JDK-8260471: bsd_aarch64 part
>  - JDK-8259539: bsd_aarch64 part
>  - JDK-8257828: bsd_aarch64 part
>  - Cleanup os_bsd_aarch64 signal handling

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 207:

> 205:   // Enable WXWrite: this function is called by the signal handler at arbitrary
> 206:   // point of execution.
> 207:   ThreadWXEnable wx(WXWrite, thread);

Note that `thread` can be NULL here if the signal handler is running in a non-attached thread.

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

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

From serb at openjdk.java.net  Wed Mar  3 06:08:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Mar 2021 06:08:05 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262915: java.awt.color.ColorSpace.getName()
 is not thread-safe
Message-ID: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>

The java.awt.color.ColorSpace.getName()  method does not use any kind of synchronization to properly initialize and use the static cache for the color components names.

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

Commit messages:
 - Update ColorSpace.java

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

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

From serb at openjdk.java.net  Wed Mar  3 06:08:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Mar 2021 06:08:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262915:
 java.awt.color.ColorSpace.getName() is not thread-safe
In-Reply-To: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
References: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
Message-ID: <XPni7sTwAId918N7LU_Z9RV1TwPNKDTst_7kpvNbi-c=.fe346405-63a5-48b4-84e4-cde9ad8a61cf@github.com>

On Wed, 3 Mar 2021 03:46:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The java.awt.color.ColorSpace.getName()  method does not use any kind of synchronization to properly initialize and use the static cache for the color components names.

src/java.desktop/share/classes/java/awt/color/ColorSpace.java line 115:

> 113:      * Lazy-initialized names of components in the color space.
> 114:      */
> 115:     private transient volatile String [] compName;

The volatile keyword is the only one necessary to fix this bug, everything else is a cleanup.

src/java.desktop/share/classes/java/awt/color/ColorSpace.java line 454:

> 452:      * Returns the name of the component given the component index.
> 453:      *
> 454:      * @param  component the component index

All other methods use the "component" as a name of the component index.

src/java.desktop/share/classes/java/awt/color/ColorSpace.java line 459:

> 457:         rangeCheck(idx);
> 458:         if (compName == null) {
> 459:             switch (type) {

the "switch statement" is replaced by the "switch expression"

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

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

From gziemski at openjdk.java.net  Wed Mar  3 16:00:00 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Mar 2021 16:00:00 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v23]
In-Reply-To: <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
 <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>
Message-ID: <SaFPzYzpXuZFUYhDvGg6PQHM-EUrSqbR02H5SzL6OvI=.77d3186b-74a5-404a-950f-95af6a13dabd@github.com>

On Tue, 2 Mar 2021 23:21:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform:
> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ? thread : Thread::current()),`
> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check.

https://bugs.openjdk.java.net/browse/JDK-8262903 tracks this issue.

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

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

From gziemski at openjdk.java.net  Wed Mar  3 17:56:15 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Mar 2021 17:56:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
Message-ID: <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>

On Tue, 2 Mar 2021 11:05:20 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> For platform files that were copied from other ports to this port, if the file wasn't
>> changed I presume the copyright years are left alone. If the file required changes
>> for this port, I expect the year to be updated to 2021. How are you verifying that
>> these copyright years are being properly managed on the new files?
>> 
>> For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment
>> explaining why one was landed in a particular place would help reviewers.
>> Also see my comment about creating a new ThreadToNativeWithWXExecFromVM
>> helper.
>> 
>> I'm stopping my review with all the src/hotspot files done for now.
>
>> For platform files that were copied from other ports to this port, if the file wasn't
>> changed I presume the copyright years are left alone. If the file required changes
>> for this port, I expect the year to be updated to 2021. How are you verifying that
>> these copyright years are being properly managed on the new files?
> 
> There are no exact copies, based on
> git -c diff.renameLimit=10000000 diff --find-copies-harder -C75% --name-status upstream/master...
> 
> So every file changed in the branch potentially needs the copyright update. All file diffs are not trivial, IMHO.
> 
> I'll run the copyright update after we fix a few remaining issues with the PR, to avoid updating copyright and changing/reverting the actual content.

A list of the bugs that our internal testing revealed so far:

https://bugs.openjdk.java.net/browse/JDK-8262952
https://bugs.openjdk.java.net/browse/JDK-8262894
https://bugs.openjdk.java.net/browse/JDK-8262895
https://bugs.openjdk.java.net/browse/JDK-8262896
https://bugs.openjdk.java.net/browse/JDK-8262897
https://bugs.openjdk.java.net/browse/JDK-8262898
https://bugs.openjdk.java.net/browse/JDK-8262899
https://bugs.openjdk.java.net/browse/JDK-8262900
https://bugs.openjdk.java.net/browse/JDK-8262901
https://bugs.openjdk.java.net/browse/JDK-8262903
https://bugs.openjdk.java.net/browse/JDK-8262904

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

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

From aph at openjdk.java.net  Wed Mar  3 17:56:15 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 3 Mar 2021 17:56:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
Message-ID: <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>

On Wed, 3 Mar 2021 17:39:28 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> A list of the bugs that our internal testing revealed so far:

Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.

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

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

From akozlov at openjdk.java.net  Wed Mar  3 19:13:59 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Mar 2021 19:13:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
Message-ID: <_eNysRZporueV4wITFZra8ng_O6dvxAIc0moIWOh95U=.bd3e669d-8efc-41e1-8fb2-e9f2f8e4d1f8@github.com>

On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> A list of the bugs that our internal testing revealed so far ...

Thank you! Some of them look like test issues, but a few need more serious consideration. I want to resolve https://bugs.openjdk.java.net/browse/JDK-8262903 at least, along with a few remaining comments.

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

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

From azvegint at openjdk.java.net  Wed Mar  3 19:47:49 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 3 Mar 2021 19:47:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262915:
 java.awt.color.ColorSpace.getName() is not thread-safe
In-Reply-To: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
References: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
Message-ID: <BlilvFIVxOguan4oJe_UBT64LSW_9ruQtaJGwVbkn9U=.e778b225-0e88-4d1b-9d26-88f92dece120@github.com>

On Wed, 3 Mar 2021 03:46:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The java.awt.color.ColorSpace.getName()  method does not use any kind of synchronization to properly initialize and use the static cache for the color components names.

Marked as reviewed by azvegint (Reviewer).

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

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

From azvegint at openjdk.java.net  Wed Mar  3 19:47:49 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 3 Mar 2021 19:47:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262915:
 java.awt.color.ColorSpace.getName() is not thread-safe
In-Reply-To: <XPni7sTwAId918N7LU_Z9RV1TwPNKDTst_7kpvNbi-c=.fe346405-63a5-48b4-84e4-cde9ad8a61cf@github.com>
References: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
 <XPni7sTwAId918N7LU_Z9RV1TwPNKDTst_7kpvNbi-c=.fe346405-63a5-48b4-84e4-cde9ad8a61cf@github.com>
Message-ID: <i3eSutIt0bhdI8Yx8dhY_7XCHo44GZGbFR80HYTPrqg=.496ebd64-313c-4c38-b26d-02e5f2644dcf@github.com>

On Wed, 3 Mar 2021 03:55:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The java.awt.color.ColorSpace.getName()  method does not use any kind of synchronization to properly initialize and use the static cache for the color components names.
>
> src/java.desktop/share/classes/java/awt/color/ColorSpace.java line 454:
> 
>> 452:      * Returns the name of the component given the component index.
>> 453:      *
>> 454:      * @param  component the component index
> 
> All other methods use the "component" as a name of the component index.

I guess it will require a CSR request.

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

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

From aivanov at openjdk.java.net  Wed Mar  3 20:12:50 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 3 Mar 2021 20:12:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262915:
 java.awt.color.ColorSpace.getName() is not thread-safe
In-Reply-To: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
References: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
Message-ID: <Hv3Iou0is51YABBhWL_O1WY25YXmomZoOpn0JFb5IDA=.1dbdcf98-b627-4eb0-aead-763242f44cf0@github.com>

On Wed, 3 Mar 2021 03:46:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The java.awt.color.ColorSpace.getName()  method does not use any kind of synchronization to properly initialize and use the static cache for the color components names.

Marked as reviewed by aivanov (Reviewer).

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

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

From serb at openjdk.java.net  Wed Mar  3 20:15:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Mar 2021 20:15:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262915:
 java.awt.color.ColorSpace.getName() is not thread-safe
In-Reply-To: <i3eSutIt0bhdI8Yx8dhY_7XCHo44GZGbFR80HYTPrqg=.496ebd64-313c-4c38-b26d-02e5f2644dcf@github.com>
References: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
 <XPni7sTwAId918N7LU_Z9RV1TwPNKDTst_7kpvNbi-c=.fe346405-63a5-48b4-84e4-cde9ad8a61cf@github.com>
 <i3eSutIt0bhdI8Yx8dhY_7XCHo44GZGbFR80HYTPrqg=.496ebd64-313c-4c38-b26d-02e5f2644dcf@github.com>
Message-ID: <C5Zb3leX7YJ25yeeYLp-VI7qIRCo0aVmj87Q7w5_6zc=.a5bdf62f-15f8-4a04-8d81-25870ee0102a@github.com>

On Wed, 3 Mar 2021 19:44:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/color/ColorSpace.java line 454:
>> 
>>> 452:      * Returns the name of the component given the component index.
>>> 453:      *
>>> 454:      * @param  component the component index
>> 
>> All other methods use the "component" as a name of the component index.
>
> I guess it will require a CSR request.

nope, it is just renaming of the parameter

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

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

From serb at openjdk.java.net  Wed Mar  3 20:30:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Mar 2021 20:30:40 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8262915:
 java.awt.color.ColorSpace.getName() is not thread-safe
In-Reply-To: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
References: <8vwxNbOTZayhg5N87z9jNQXbnwEvTz__pqCZrXWyo8Y=.3767f178-fdd3-42f3-9896-0e5834fd92b7@github.com>
Message-ID: <rLP1ynVybyGEx4fJQY6Dov12gvGseIGZ6VR5k_az3fo=.a7559767-a025-4c84-8e72-68e3788cdbbe@github.com>

On Wed, 3 Mar 2021 03:46:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The java.awt.color.ColorSpace.getName()  method does not use any kind of synchronization to properly initialize and use the static cache for the color components names.

This pull request has now been integrated.

Changeset: b397472e
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b397472e
Stats:     53 lines in 1 file changed: 5 ins; 24 del; 24 mod

8262915: java.awt.color.ColorSpace.getName() is not thread-safe

Reviewed-by: azvegint, aivanov

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

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

From philip.race at oracle.com  Wed Mar  3 21:51:05 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 3 Mar 2021 13:51:05 -0800
Subject: [OpenJDK 2D-Dev] Project Lanai (New Metal Java 2D Rendering
 pipeline for macOS) EA build 10 has been released
Message-ID: <d012d25b-e6db-fcbf-619b-ed9324e3713b@oracle.com>

All,

We have prepared an EA 10 build of Project Lanai for JEP 382 [1] 
incorporating fixes to feed back during the ongoing code review [2]
EA 10 can be downloaded from https://jdk.java.net/lanai/.

Note the open issues and testing suggestions given there.

Please test with your apps and hardware and provide feedback via the 
lanai-dev at openjdk.java.net mailing list.

-Phil

[1] https://openjdk.java.net/jeps/382
[2] https://mail.openjdk.java.net/pipermail/2d-dev/2021-February/011902.html


From dmarkov at openjdk.java.net  Thu Mar  4 10:41:47 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Thu, 4 Mar 2021 10:41:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows
Message-ID: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>

The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.

Fix:
Introduce a new flag to indicate DND operation between Java and native app. 

Testing:
mach5 green

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

Commit messages:
 - 8262446: DragAndDrop hangs on Windows

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

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

From gziemski at openjdk.java.net  Thu Mar  4 15:29:59 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Mar 2021 15:29:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
Message-ID: <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>

On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > A list of the bugs that our internal testing revealed so far:
> 
> Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.

I don't personally think any of these issues are blockers. It's a great effort as it is and very much appreciated. Anything else can be fixed as a followup.

There might be some legal requirements (i.e. JCK) that I'm not in position to comment on, however, so someone else might need to chime in here.

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

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

From github.com+4146708+a74nh at openjdk.java.net  Thu Mar  4 17:39:01 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Thu, 4 Mar 2021 17:39:01 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
Message-ID: <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>

On Thu, 4 Mar 2021 15:27:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>>> A list of the bugs that our internal testing revealed so far:
>> 
>> Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.
>
>> > A list of the bugs that our internal testing revealed so far:
>> 
>> Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.
> 
> I don't personally think any of these issues are blockers. It's a great effort as it is and very much appreciated. Anything else can be fixed as a followup.
> 
> There might be some legal requirements (i.e. JCK) that I'm not in position to comment on, however, so someone else might need to chime in here.

I was building this PR on a new machine, and I now get the following error:

> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> static MIDIClientRef client = (MIDIClientRef) NULL;
>                               ^~~~~~~~~~~~~~~~~~~~
> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> static MIDIPortRef inPort = (MIDIPortRef) NULL;
>                             ^~~~~~~~~~~~~~~~~~
> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> static MIDIPortRef outPort = (MIDIPortRef) NULL;
>                              ^~~~~~~~~~~~~~~~~~
> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>     MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
>                                ^~~~~~~~~~~~~~~~~~~~~~
> 4 errors generated.

As far as I can tell the only difference between the two systems is the xcode version:

New system (failing)
% xcodebuild -version
Xcode 12.5
Build version 12E5244e

Old system (working)
% xcodebuild -version
Xcode 12.4
Build version 12D4e

Looks like the newer version of Xcode is being a little stricter with casting?
Replacing the NULL with 0 seems to fix the issue.

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

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

From vkempik at openjdk.java.net  Thu Mar  4 18:22:51 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 4 Mar 2021 18:22:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
 <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
Message-ID: <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>

On Thu, 4 Mar 2021 17:36:22 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> I was building this PR on a new machine, and I now get the following error:
> 
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIClientRef client = (MIDIClientRef) NULL;
> > ^~~~~~~~~~~~~~~~~~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef inPort = (MIDIPortRef) NULL;
> > ^~~~~~~~~~~~~~~~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef outPort = (MIDIPortRef) NULL;
> > ^~~~~~~~~~~~~~~~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
> > ^~~~~~~~~~~~~~~~~~~~~~
> > 4 errors generated.
> 
> As far as I can tell the only difference between the two systems is the xcode version:
> 
> New system (failing)
> % xcodebuild -version
> Xcode 12.5
> Build version 12E5244e
> 
> Old system (working)
> % xcodebuild -version
> Xcode 12.4
> Build version 12D4e
> 
> Looks like the newer version of Xcode is being a little stricter with casting?
> Replacing the NULL with 0 seems to fix the issue.

Hello
there is one issue with the info you provided, it's from Xcode12.5 beta.
And beta license agreement forbids sharing output of beta version of compiler&co
So we can't say we have issue with newer xcode beta until that beta went public & released.
Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.

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

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

From aivanov at openjdk.java.net  Thu Mar  4 19:41:45 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 4 Mar 2021 19:41:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows
In-Reply-To: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
Message-ID: <3AXLyReWRtjcMeVZpQZAO2VNpJDbCfzQ5sTcArhcj1A=.fc9957b9-3928-4f2a-a291-26ef03e82659@github.com>

On Thu, 4 Mar 2021 10:36:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
> 
> Fix:
> Introduce a new flag to indicate DND operation between Java and native app. 
> 
> Testing:
> mach5 green

Marked as reviewed by aivanov (Reviewer).

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

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

From aivanov at openjdk.java.net  Thu Mar  4 21:42:53 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 4 Mar 2021 21:42:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
Message-ID: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>

**Root cause:**
`getPrinterNames()` has two calls to [`::EnumPrinters`](https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters). The first call is to get the required buffer size to contain the structures and any strings. The second call is to get the list of printers.

Yet the list of printers or the names of printers can change between the two calls. If it happens, the second call to `EnumPrinters` fails but it is not checked.

I couldn't reproduce the crash myself. However, I reproduced the failure in the second call to `::EnumPrinters` by adding `::Sleep(500)` and by renaming the printers so that the data doesn't fit into the allocated buffer:

1: bResult: 0, cbNeeded: 504, cReturned: 0
2: bResult: 0, cbNeeded: 512, cReturned: 0
    !!! error

During my testing, `cReturned` has always been zero whenever `EnumPrinters` fails.

The crash dumps show that `cReturned` is non-zero but the `pPrinterEnum` buffer doesn't contain valid data. Reading `info4->pPrinterName` at the line
utf_str = JNU_NewStringPlatform(env, info4->pPrinterName);
raises Access Violation exception.

**The fix:**
Check the return value of `EnumPrinters` and allow for 5 retries. If the function still returns failure, make sure `cReturned` is set to zero.

I'm going to close [JDK-6996051](https://bugs.openjdk.java.net/browse/JDK-6996051) and [JDK-8182683](https://bugs.openjdk.java.net/browse/JDK-8182683) reported previously about the same crash as duplicate of the current [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829).

**Testing:**
I used [`RemotePrinterStatusRefresh.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java) for testing, it shows the list of currently available printers. In the background I ran `PrinterRename.ps1` PowerShell script which remains a printer, the script is attached to the JBS issue.

Without the fix, the list of available printers was empty occasionally because `EnumPrinters` returned failure and set `cReturned` to zero. With the fix, the list of printers is always filled.

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

Commit messages:
 - 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames()

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

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

From prr at openjdk.java.net  Thu Mar  4 22:12:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 4 Mar 2021 22:12:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
In-Reply-To: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
References: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
Message-ID: <tHlo5Y7iDx6ENGOIrH2ixqjnJZcWMcy0cbexfGH6bBM=.43c1c62a-7bb0-4ddb-b46a-ad1e47c08987@github.com>

On Thu, 4 Mar 2021 21:37:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Root cause:**
> `getPrinterNames()` has two calls to [`::EnumPrinters`](https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters). The first call is to get the required buffer size to contain the structures and any strings. The second call is to get the list of printers.
> 
> Yet the list of printers or the names of printers can change between the two calls. If it happens, the second call to `EnumPrinters` fails but it is not checked.
> 
> I couldn't reproduce the crash myself. However, I reproduced the failure in the second call to `::EnumPrinters` by adding `::Sleep(500)` and by renaming the printers so that the data doesn't fit into the allocated buffer:
> 
> 1: bResult: 0, cbNeeded: 504, cReturned: 0
> 2: bResult: 0, cbNeeded: 512, cReturned: 0
>     !!! error
> 
> During my testing, `cReturned` has always been zero whenever `EnumPrinters` fails.
> 
> The crash dumps show that `cReturned` is non-zero but the `pPrinterEnum` buffer doesn't contain valid data. Reading `info4->pPrinterName` at the line
> utf_str = JNU_NewStringPlatform(env, info4->pPrinterName);
> raises Access Violation exception.
> 
> **The fix:**
> Check the return value of `EnumPrinters` and allow for 5 retries. If the function still returns failure, make sure `cReturned` is set to zero.
> 
> I'm going to close [JDK-6996051](https://bugs.openjdk.java.net/browse/JDK-6996051) and [JDK-8182683](https://bugs.openjdk.java.net/browse/JDK-8182683) reported previously about the same crash as duplicate of the current [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829).
> 
> **Testing:**
> I used [`RemotePrinterStatusRefresh.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java) for testing, it shows the list of currently available printers. In the background I ran `PrinterRename.ps1` PowerShell script which remains a printer, the script is attached to the JBS issue.
> 
> Without the fix, the list of available printers was empty occasionally because `EnumPrinters` returned failure and set `cReturned` to zero. With the fix, the list of printers is always filled.

I guess this is OK and yes we should have been checking this.
Not sure we really got to the bottom of the real world problem because I'd expect the 2nd call just milliseconds after the first. But it could be that this happens during some system updates and we get one printer reconfigured message followed by another ..

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

Marked as reviewed by prr (Reviewer).

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

From serb at openjdk.java.net  Fri Mar  5 01:30:52 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 5 Mar 2021 01:30:52 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
In-Reply-To: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
References: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
Message-ID: <QJHCbyLZH6v1qgBJlSAuwiDlXKHmxyVs24a2PXVEVK4=.d3bf3fa0-1992-4cee-8994-9bf690f5e4e1@github.com>

On Thu, 4 Mar 2021 21:37:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Root cause:**
> `getPrinterNames()` has two calls to [`::EnumPrinters`](https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters). The first call is to get the required buffer size to contain the structures and any strings. The second call is to get the list of printers.
> 
> Yet the list of printers or the names of printers can change between the two calls. If it happens, the second call to `EnumPrinters` fails but it is not checked.
> 
> I couldn't reproduce the crash myself. However, I reproduced the failure in the second call to `::EnumPrinters` by adding `::Sleep(500)` and by renaming the printers so that the data doesn't fit into the allocated buffer:
> 
> 1: bResult: 0, cbNeeded: 504, cReturned: 0
> 2: bResult: 0, cbNeeded: 512, cReturned: 0
>     !!! error
> 
> During my testing, `cReturned` has always been zero whenever `EnumPrinters` fails.
> 
> The crash dumps show that `cReturned` is non-zero but the `pPrinterEnum` buffer doesn't contain valid data. Reading `info4->pPrinterName` at the line
> utf_str = JNU_NewStringPlatform(env, info4->pPrinterName);
> raises Access Violation exception.
> 
> **The fix:**
> Check the return value of `EnumPrinters` and allow for 5 retries. If the function still returns failure, make sure `cReturned` is set to zero.
> 
> I'm going to close [JDK-6996051](https://bugs.openjdk.java.net/browse/JDK-6996051) and [JDK-8182683](https://bugs.openjdk.java.net/browse/JDK-8182683) reported previously about the same crash as duplicate of the current [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829).
> 
> **Testing:**
> I used [`RemotePrinterStatusRefresh.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java) for testing, it shows the list of currently available printers. In the background I ran `PrinterRename.ps1` PowerShell script which remains a printer, the script is attached to the JBS issue.
> 
> Without the fix, the list of available printers was empty occasionally because `EnumPrinters` returned failure and set `cReturned` to zero. With the fix, the list of printers is always filled.

src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp line 136:

> 134: 
> 135:     try {
> 136:         ::EnumPrinters(flags, NULL, 4, NULL,

Don't we need to check that this method call succeeds? Probably it is a crash reason when the EnumPrinters fails but we use cbNeeded anyway for array allocation?

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

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

From serb at openjdk.java.net  Fri Mar  5 01:36:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 5 Mar 2021 01:36:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows
In-Reply-To: <3AXLyReWRtjcMeVZpQZAO2VNpJDbCfzQ5sTcArhcj1A=.fc9957b9-3928-4f2a-a291-26ef03e82659@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
 <3AXLyReWRtjcMeVZpQZAO2VNpJDbCfzQ5sTcArhcj1A=.fc9957b9-3928-4f2a-a291-26ef03e82659@github.com>
Message-ID: <s6Q8Sfuh3ObtCwaRXTdW3H5t_JQXeXUjeKPs-tDUpN8=.d840a28b-d603-437e-85ac-7682bf321279@github.com>

On Thu, 4 Mar 2021 19:38:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
>> 
>> Fix:
>> Introduce a new flag to indicate DND operation between Java and native app. 
>> 
>> Testing:
>> mach5 green
>
> Marked as reviewed by aivanov (Reviewer).

Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while dragging something from the native app.

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

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

From psadhukhan at openjdk.java.net  Fri Mar  5 03:45:51 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 5 Mar 2021 03:45:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
In-Reply-To: <QJHCbyLZH6v1qgBJlSAuwiDlXKHmxyVs24a2PXVEVK4=.d3bf3fa0-1992-4cee-8994-9bf690f5e4e1@github.com>
References: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
 <QJHCbyLZH6v1qgBJlSAuwiDlXKHmxyVs24a2PXVEVK4=.d3bf3fa0-1992-4cee-8994-9bf690f5e4e1@github.com>
Message-ID: <ee627eglgSyJgtbvOf8XRaIq7e4EhaSnYmmVNuiF-0k=.083077c4-fa12-4a51-a87c-7de4aa42126c@github.com>

On Fri, 5 Mar 2021 01:27:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> **Root cause:**
>> `getPrinterNames()` has two calls to [`::EnumPrinters`](https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters). The first call is to get the required buffer size to contain the structures and any strings. The second call is to get the list of printers.
>> 
>> Yet the list of printers or the names of printers can change between the two calls. If it happens, the second call to `EnumPrinters` fails but it is not checked.
>> 
>> I couldn't reproduce the crash myself. However, I reproduced the failure in the second call to `::EnumPrinters` by adding `::Sleep(500)` and by renaming the printers so that the data doesn't fit into the allocated buffer:
>> 
>> 1: bResult: 0, cbNeeded: 504, cReturned: 0
>> 2: bResult: 0, cbNeeded: 512, cReturned: 0
>>     !!! error
>> 
>> During my testing, `cReturned` has always been zero whenever `EnumPrinters` fails.
>> 
>> The crash dumps show that `cReturned` is non-zero but the `pPrinterEnum` buffer doesn't contain valid data. Reading `info4->pPrinterName` at the line
>> utf_str = JNU_NewStringPlatform(env, info4->pPrinterName);
>> raises Access Violation exception.
>> 
>> **The fix:**
>> Check the return value of `EnumPrinters` and allow for 5 retries. If the function still returns failure, make sure `cReturned` is set to zero.
>> 
>> I'm going to close [JDK-6996051](https://bugs.openjdk.java.net/browse/JDK-6996051) and [JDK-8182683](https://bugs.openjdk.java.net/browse/JDK-8182683) reported previously about the same crash as duplicate of the current [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829).
>> 
>> **Testing:**
>> I used [`RemotePrinterStatusRefresh.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java) for testing, it shows the list of currently available printers. In the background I ran `PrinterRename.ps1` PowerShell script which remains a printer, the script is attached to the JBS issue.
>> 
>> Without the fix, the list of available printers was empty occasionally because `EnumPrinters` returned failure and set `cReturned` to zero. With the fix, the list of printers is always filled.
>
> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp line 136:
> 
>> 134: 
>> 135:     try {
>> 136:         ::EnumPrinters(flags, NULL, 4, NULL,
> 
> Don't we need to check that this method call succeeds? Probably it is a crash reason when the EnumPrinters fails but we use cbNeeded anyway for array allocation?

I guess since we are changing this method anyway, can we use PRINTER_ENUM_CONNECTIONS flag instead of hardcoded 4 so that it is more informative!!

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

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

From psadhukhan at openjdk.java.net  Fri Mar  5 03:51:47 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 5 Mar 2021 03:51:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
In-Reply-To: <ee627eglgSyJgtbvOf8XRaIq7e4EhaSnYmmVNuiF-0k=.083077c4-fa12-4a51-a87c-7de4aa42126c@github.com>
References: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
 <QJHCbyLZH6v1qgBJlSAuwiDlXKHmxyVs24a2PXVEVK4=.d3bf3fa0-1992-4cee-8994-9bf690f5e4e1@github.com>
 <ee627eglgSyJgtbvOf8XRaIq7e4EhaSnYmmVNuiF-0k=.083077c4-fa12-4a51-a87c-7de4aa42126c@github.com>
Message-ID: <0hcch0AQLe8r7klFBtxMgbGCymZgZs4I8XXi_htxEhg=.08f56689-263e-496f-9c16-60326ddc08f9@github.com>

On Fri, 5 Mar 2021 03:42:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp line 136:
>> 
>>> 134: 
>>> 135:     try {
>>> 136:         ::EnumPrinters(flags, NULL, 4, NULL,
>> 
>> Don't we need to check that this method call succeeds? Probably it is a crash reason when the EnumPrinters fails but we use cbNeeded anyway for array allocation?
>
> I guess since we are changing this method anyway, can we use PRINTER_ENUM_CONNECTIONS flag instead of hardcoded 4 so that it is more informative!!

ok, it is for flags and not for level. please ignore

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

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

From itakiguchi at openjdk.java.net  Fri Mar  5 07:02:50 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 5 Mar 2021 07:02:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows
In-Reply-To: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
Message-ID: <G6cVplWrk4kOOZ3vC7kNN7Y8jO1rqpFYOO7_PzzI8K4=.8bad46ae-0aee-458e-8327-9e5b156c14c7@github.com>

On Thu, 4 Mar 2021 10:36:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
> 
> Fix:
> Introduce a new flag to indicate DND operation between Java and native app. 
> 
> Testing:
> mach5 green

@dmarkov20 
I'd like to confirm this issue was not fixed by [JDK-8261231](https://bugs.openjdk.java.net/browse/JDK-8261231) #2448 ?

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

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

From aivanov at openjdk.java.net  Fri Mar  5 10:56:53 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 5 Mar 2021 10:56:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
In-Reply-To: <0hcch0AQLe8r7klFBtxMgbGCymZgZs4I8XXi_htxEhg=.08f56689-263e-496f-9c16-60326ddc08f9@github.com>
References: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
 <QJHCbyLZH6v1qgBJlSAuwiDlXKHmxyVs24a2PXVEVK4=.d3bf3fa0-1992-4cee-8994-9bf690f5e4e1@github.com>
 <ee627eglgSyJgtbvOf8XRaIq7e4EhaSnYmmVNuiF-0k=.083077c4-fa12-4a51-a87c-7de4aa42126c@github.com>
 <0hcch0AQLe8r7klFBtxMgbGCymZgZs4I8XXi_htxEhg=.08f56689-263e-496f-9c16-60326ddc08f9@github.com>
Message-ID: <xN2kwXUK454zPQBidKA3jVmiWn-hDL8Sv9eRwuTWquo=.6e9e89a1-8fd4-4390-b890-f27d6b4f3f37@github.com>

On Fri, 5 Mar 2021 03:49:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I guess since we are changing this method anyway, can we use PRINTER_ENUM_CONNECTIONS flag instead of hardcoded 4 so that it is more informative!!
>
> ok, it is for flags and not for level. please ignore

> 
> 
> Don't we need to check that this method call succeeds? Probably it is a crash reason when the EnumPrinters fails but we use cbNeeded anyway for array allocation?

`EnumPrinters` always returns failure here because zero-sized buffer is too small to contain any data.

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

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

From aivanov at openjdk.java.net  Fri Mar  5 11:14:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 5 Mar 2021 11:14:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
In-Reply-To: <tHlo5Y7iDx6ENGOIrH2ixqjnJZcWMcy0cbexfGH6bBM=.43c1c62a-7bb0-4ddb-b46a-ad1e47c08987@github.com>
References: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
 <tHlo5Y7iDx6ENGOIrH2ixqjnJZcWMcy0cbexfGH6bBM=.43c1c62a-7bb0-4ddb-b46a-ad1e47c08987@github.com>
Message-ID: <7tAblZFGvqlEUVq6JiaAelhM-euv_OXcptNFMyEWU7w=.b133553b-79ea-4e1b-8570-2d083946cb77@github.com>

On Thu, 4 Mar 2021 22:09:55 GMT, Phil Race <prr at openjdk.org> wrote:

> I guess this is OK and yes we should have been checking this.
> Not sure we really got to the bottom of the real world problem because I'd expect the 2nd call just milliseconds after the first. But it could be that this happens during some system updates and we get one printer reconfigured message followed by another ..

Most of the time, the crash happens when a client reconnects to their active session where a JVM is already running. On reconnect, the list of printers is synced with the local printers on the client. In such a scenario, other software could also update its list of printers as well as repaint its UI. If the system is under high load, it's not impossible to have a long enough pause between the calls.

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

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

From github.com+4146708+a74nh at openjdk.java.net  Fri Mar  5 11:14:49 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Fri, 5 Mar 2021 11:14:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
 <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
 <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>
Message-ID: <ALwCIkHXaVHDCuuko2Vku6HZhRqcVV26sF52Jxl7VvI=.0ba86f48-03fd-46d1-93c3-f2a12effe999@github.com>

On Thu, 4 Mar 2021 18:19:33 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Hello
> there is one issue with the info you provided, it's from Xcode12.5 beta.
> And beta license agreement forbids sharing output of beta version of compiler&co
> So we can't say we have issue with newer xcode beta until that beta went public & released.
> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.

Ok, I wasn't aware of that. I'll downgrade back to the non-beta version.

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

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

From psadhukhan at openjdk.java.net  Fri Mar  5 11:22:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 5 Mar 2021 11:22:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
In-Reply-To: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
References: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
Message-ID: <kSVidCYkwY7BUqmVFMMPXEivVd4GVl0GSZ88J4a0m_g=.3023d361-7746-487a-8f5b-066a1a0d6791@github.com>

On Thu, 4 Mar 2021 21:37:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Root cause:**
> `getPrinterNames()` has two calls to [`::EnumPrinters`](https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters). The first call is to get the required buffer size to contain the structures and any strings. The second call is to get the list of printers.
> 
> Yet the list of printers or the names of printers can change between the two calls. If it happens, the second call to `EnumPrinters` fails but it is not checked.
> 
> I couldn't reproduce the crash myself. However, I reproduced the failure in the second call to `::EnumPrinters` by adding `::Sleep(500)` and by renaming the printers so that the data doesn't fit into the allocated buffer:
> 
> 1: bResult: 0, cbNeeded: 504, cReturned: 0
> 2: bResult: 0, cbNeeded: 512, cReturned: 0
>     !!! error
> 
> During my testing, `cReturned` has always been zero whenever `EnumPrinters` fails.
> 
> The crash dumps show that `cReturned` is non-zero but the `pPrinterEnum` buffer doesn't contain valid data. Reading `info4->pPrinterName` at the line
> utf_str = JNU_NewStringPlatform(env, info4->pPrinterName);
> raises Access Violation exception.
> 
> **The fix:**
> Check the return value of `EnumPrinters` and allow for 5 retries. If the function still returns failure, make sure `cReturned` is set to zero.
> 
> I'm going to close [JDK-6996051](https://bugs.openjdk.java.net/browse/JDK-6996051) and [JDK-8182683](https://bugs.openjdk.java.net/browse/JDK-8182683) reported previously about the same crash as duplicate of the current [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829).
> 
> **Testing:**
> I used [`RemotePrinterStatusRefresh.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java) for testing, it shows the list of currently available printers. In the background I ran `PrinterRename.ps1` PowerShell script which remains a printer, the script is attached to the JBS issue.
> 
> Without the fix, the list of available printers was empty occasionally because `EnumPrinters` returned failure and set `cReturned` to zero. With the fix, the list of printers is always filled.

Marked as reviewed by psadhukhan (Reviewer).

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

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

From dmarkov at openjdk.java.net  Fri Mar  5 16:06:04 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Fri, 5 Mar 2021 16:06:04 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
In-Reply-To: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
Message-ID: <y-sYWXImtv-iTWyG9bU8uxvgpnt6C_xFEGQ-2l9z3J8=.0889ac82-62d0-409a-b6d6-fd77f22cc282@github.com>

> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
> 
> Fix:
> Introduce a new flag to indicate DND operation between Java and native app. 
> 
> Testing:
> mach5 green

Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:

  reuse isInDoDragDropLoop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2825/files
  - new: https://git.openjdk.java.net/jdk/pull/2825/files/6d7502a4..d9af9879

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

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

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

From dmarkov at openjdk.java.net  Fri Mar  5 16:06:15 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Fri, 5 Mar 2021 16:06:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
In-Reply-To: <s6Q8Sfuh3ObtCwaRXTdW3H5t_JQXeXUjeKPs-tDUpN8=.d840a28b-d603-437e-85ac-7682bf321279@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
 <3AXLyReWRtjcMeVZpQZAO2VNpJDbCfzQ5sTcArhcj1A=.fc9957b9-3928-4f2a-a291-26ef03e82659@github.com>
 <s6Q8Sfuh3ObtCwaRXTdW3H5t_JQXeXUjeKPs-tDUpN8=.d840a28b-d603-437e-85ac-7682bf321279@github.com>
Message-ID: <t71N-XIthjL0aLTZD7hqRfAIKoOW5TPLWODw9nQsoDc=.f9d5e4d8-bb45-4cac-88e9-67d285693af7@github.com>

On Fri, 5 Mar 2021 01:34:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while dragging something from the native app.

Initially I didn?t want to touch that flag but after a closer look to ?isInDoDragDropLoop? I think it is OK to reuse the flag. I will update PR shortly.

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

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

From dmarkov at openjdk.java.net  Fri Mar  5 16:06:21 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Fri, 5 Mar 2021 16:06:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
In-Reply-To: <0FK7NORAeG5R8F7Xv2OdslzNQE-hfozCyWM-KOE1NgU=.78b0f2b0-1a36-495a-9547-f1436d908c67@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
 <3AXLyReWRtjcMeVZpQZAO2VNpJDbCfzQ5sTcArhcj1A=.fc9957b9-3928-4f2a-a291-26ef03e82659@github.com>
 <s6Q8Sfuh3ObtCwaRXTdW3H5t_JQXeXUjeKPs-tDUpN8=.d840a28b-d603-437e-85ac-7682bf321279@github.com>
 <t71N-XIthjL0aLTZD7hqRfAIKoOW5TPLWODw9nQsoDc=.f9d5e4d8-bb45-4cac-88e9-67d285693af7@github.com>
 <0FK7NORAeG5R8F7Xv2OdslzNQE-hfozCyWM-KOE1NgU=.78b0f2b0-1a36-495a-9547-f1436d908c67@github.com>
Message-ID: <C0ieBjeU7KrkgMBxxCl0z2_grQsQ2KHp15OG9QFu3pA=.08628ab4-42f5-4a58-96ec-f4c710637797@github.com>

On Fri, 5 Mar 2021 12:53:00 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>>> Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while dragging something from the native app.
>> 
>> Initially I didn?t want to touch that flag but after a closer look to ?isInDoDragDropLoop? I think it is OK to reuse the flag. I will update PR shortly.
>
>> @dmarkov20
>> I'd like to confirm this issue was not fixed by [JDK-8261231](https://bugs.openjdk.java.net/browse/JDK-8261231) #2448 ?
> 
> That's right. This one and JDK-8261231 are two different issues. It is expected that the changes for JDK-8261231 do not fix this.

I have update the fix: reuse isInDoDragDropLoop flag instead of introducing a new one.
@mrserb @aivanov-jdk 
Could you take a look, please?

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

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

From dmarkov at openjdk.java.net  Fri Mar  5 16:06:15 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Fri, 5 Mar 2021 16:06:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
In-Reply-To: <t71N-XIthjL0aLTZD7hqRfAIKoOW5TPLWODw9nQsoDc=.f9d5e4d8-bb45-4cac-88e9-67d285693af7@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
 <3AXLyReWRtjcMeVZpQZAO2VNpJDbCfzQ5sTcArhcj1A=.fc9957b9-3928-4f2a-a291-26ef03e82659@github.com>
 <s6Q8Sfuh3ObtCwaRXTdW3H5t_JQXeXUjeKPs-tDUpN8=.d840a28b-d603-437e-85ac-7682bf321279@github.com>
 <t71N-XIthjL0aLTZD7hqRfAIKoOW5TPLWODw9nQsoDc=.f9d5e4d8-bb45-4cac-88e9-67d285693af7@github.com>
Message-ID: <0FK7NORAeG5R8F7Xv2OdslzNQE-hfozCyWM-KOE1NgU=.78b0f2b0-1a36-495a-9547-f1436d908c67@github.com>

On Fri, 5 Mar 2021 12:51:15 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while dragging something from the native app.
>
>> Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while dragging something from the native app.
> 
> Initially I didn?t want to touch that flag but after a closer look to ?isInDoDragDropLoop? I think it is OK to reuse the flag. I will update PR shortly.

> @dmarkov20
> I'd like to confirm this issue was not fixed by [JDK-8261231](https://bugs.openjdk.java.net/browse/JDK-8261231) #2448 ?

That's right. This one and JDK-8261231 are two different issues. It is expected that the changes for JDK-8261231 do not fix this.

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

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

From aivanov at openjdk.java.net  Fri Mar  5 17:06:23 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 5 Mar 2021 17:06:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
In-Reply-To: <y-sYWXImtv-iTWyG9bU8uxvgpnt6C_xFEGQ-2l9z3J8=.0889ac82-62d0-409a-b6d6-fd77f22cc282@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
 <y-sYWXImtv-iTWyG9bU8uxvgpnt6C_xFEGQ-2l9z3J8=.0889ac82-62d0-409a-b6d6-fd77f22cc282@github.com>
Message-ID: <fndpz8VQrjuVw4L0r7IIYsa_rK1Z82bya2lTP98S1s0=.8dc96572-9bbb-4744-9441-042f5c373de1@github.com>

On Fri, 5 Mar 2021 16:06:04 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
>> 
>> Fix:
>> Introduce a new flag to indicate DND operation between Java and native app. 
>> 
>> Testing:
>> mach5 green
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reuse isInDoDragDropLoop

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp line 228:

> 226: HRESULT __stdcall AwtDropTarget::DragOver(DWORD grfKeyState, POINTL pt, DWORD __RPC_FAR *pdwEffect) {
> 227:     TRY;
> 228:     AwtToolkit::GetInstance().isInDoDragDropLoop = TRUE;

This is a new addition. Did you miss this function in previous iteration?

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

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

From dmarkov at openjdk.java.net  Fri Mar  5 17:21:37 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Fri, 5 Mar 2021 17:21:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v2]
In-Reply-To: <fndpz8VQrjuVw4L0r7IIYsa_rK1Z82bya2lTP98S1s0=.8dc96572-9bbb-4744-9441-042f5c373de1@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
 <y-sYWXImtv-iTWyG9bU8uxvgpnt6C_xFEGQ-2l9z3J8=.0889ac82-62d0-409a-b6d6-fd77f22cc282@github.com>
 <fndpz8VQrjuVw4L0r7IIYsa_rK1Z82bya2lTP98S1s0=.8dc96572-9bbb-4744-9441-042f5c373de1@github.com>
Message-ID: <OKHmwhnHzKCUHKb_b9Zx5tMRn9Tzd_U1JYpLvt5BEHs=.157272a3-966f-41d4-9990-8aebc6006ae7@github.com>

On Fri, 5 Mar 2021 17:01:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reuse isInDoDragDropLoop
>
> src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp line 228:
> 
>> 226: HRESULT __stdcall AwtDropTarget::DragOver(DWORD grfKeyState, POINTL pt, DWORD __RPC_FAR *pdwEffect) {
>> 227:     TRY;
>> 228:     AwtToolkit::GetInstance().isInDoDragDropLoop = TRUE;
> 
> This is a new addition. Did you miss this function in previous iteration?

Good catch! Actually that line is harmless but it is really unnecessary. I will update PR

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

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

From dmarkov at openjdk.java.net  Fri Mar  5 17:21:36 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Fri, 5 Mar 2021 17:21:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v3]
In-Reply-To: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
Message-ID: <RrkHIgDAJvTf8YsG5F2Y8mEKRlnJadhb_BB74OZtrmo=.babb71a8-e9a9-4039-88b4-86c8c5f8af5e@github.com>

> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
> 
> Fix:
> Introduce a new flag to indicate DND operation between Java and native app. 
> 
> Testing:
> mach5 green

Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:

  Remove flag setting from DragOver

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2825/files
  - new: https://git.openjdk.java.net/jdk/pull/2825/files/d9af9879..dbc9dac7

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

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

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

From rrich at openjdk.java.net  Fri Mar  5 17:28:24 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 5 Mar 2021 17:28:24 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <ALwCIkHXaVHDCuuko2Vku6HZhRqcVV26sF52Jxl7VvI=.0ba86f48-03fd-46d1-93c3-f2a12effe999@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
 <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
 <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>
 <ALwCIkHXaVHDCuuko2Vku6HZhRqcVV26sF52Jxl7VvI=.0ba86f48-03fd-46d1-93c3-f2a12effe999@github.com>
Message-ID: <lQbCTtxrMGtcQ9annTOJa_zUPL3db1ETRwVp2sBJ5qA=.611f9f30-fcfa-4f3d-b9b3-11a03b012fb3@github.com>

On Fri, 5 Mar 2021 11:11:44 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>>> I was building this PR on a new machine, and I now get the following error:
>>> 
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > static MIDIClientRef client = (MIDIClientRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~~~
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > static MIDIPortRef inPort = (MIDIPortRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > static MIDIPortRef outPort = (MIDIPortRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~~~~~
>>> > 4 errors generated.
>>> 
>>> As far as I can tell the only difference between the two systems is the xcode version:
>>> 
>>> New system (failing)
>>> % xcodebuild -version
>>> Xcode 12.5
>>> Build version 12E5244e
>>> 
>>> Old system (working)
>>> % xcodebuild -version
>>> Xcode 12.4
>>> Build version 12D4e
>>> 
>>> Looks like the newer version of Xcode is being a little stricter with casting?
>>> Replacing the NULL with 0 seems to fix the issue.
>> 
>> Hello
>> there is one issue with the info you provided, it's from Xcode12.5 beta.
>> And beta license agreement forbids sharing output of beta version of compiler&co
>> So we can't say we have issue with newer xcode beta until that beta went public & released.
>> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.
>
>> Hello
>> there is one issue with the info you provided, it's from Xcode12.5 beta.
>> And beta license agreement forbids sharing output of beta version of compiler&co
>> So we can't say we have issue with newer xcode beta until that beta went public & released.
>> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.
> 
> Ok, I wasn't aware of that. I'll downgrade back to the non-beta version.

Hi,

@VladimirKempik reported failure of CompressedClassPointers.largeHeapAbove32GTest() with [JDK-8262895](https://bugs.openjdk.java.net/browse/JDK-8262895) on macos_aarch64.

He also helped analyzing the issue (thanks!).

Apparently the vm has difficulties mapping the heap of 31GB at one of the preferred addresses given in
[`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477). This causes the test failure indirectly.

IMO it could be worth the effort to find out why the heap cannot be mapped at the preferred addresses. Reviewers should decide on it. I wouldn't be able to do it myself though as I don't have access to a macos_aarch64 system.

Alternatively I'd suggest to exlude macos_aarch64 from the subtest largeHeapAbove32GTest.

Best regards,
Richard.

--

#### Details of the analysis

In the following trace we see the vm trying to allocate the heap at addresses given in [`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477) without success:

images/jdk/bin/java  -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -Xmx31g -XX:-UseAOT -Xlog:gc+metaspace=trace,cds=trace,heap+gc+exit=info,gc+heap+coops=trace -Xshare:off -XX:+VerifyBeforeGC -XX:HeapSearchSteps=40 -version
OpenJDK 64-Bit Server VM warning: Shared spaces are not supported in this VM
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001800000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000002000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000004000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000005000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0008000000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0010000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0018000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0020000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0080000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0100000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0110000000000000 heap of size 0x7c1000000

Finally it gives up and lets the os chose the address:

[0.006s][trace][gc,heap,coops] Trying to allocate at address NULL heap of size 0x7c1000000
[0.006s][debug][gc,heap,coops] Protected page at the reserved heap base: 0x0000000280000000 / 16777216 bytes
[0.006s][debug][gc,heap,coops] Heap address: 0x0000000281000000, size: 31744 MB, Compressed Oops mode: Non-zero based: 0x0000000280000000, Oop shift amount: 3

The os chooses to map the heap at 0x0000000281000000 that is at 10GB. This leaves not much room for a 4GB (*) aligned compressed class space below 32G for a zero based encoding. And indeed we get a compressed class space with an encoding base that is not zero and largeHeapAbove32GTest fails then

[0.007s][info ][gc,metaspace ] Compressed class space mapped at: 0x0000007000000000-0x0000007040000000, reserved size: 1073741824
[0.007s][info ][gc,metaspace ] Narrow klass base: 0x0000007000000000, Narrow klass shift: 0, Narrow klass range: 0x40000000
On macos 10.15 (x86_64) the vm succeeds first try mapping the heap at address 0x0000001000000000.

(*) On aarch64 the encoding base has to be 4GB aligned. Unfortunately the 4GB alignment is enforced to strictly on the start address of the compressed class space instead of enforcing it on the encoding base. See [JDK-8258756](https://bugs.openjdk.java.net/browse/JDK-8258756)

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

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

From aivanov at openjdk.java.net  Fri Mar  5 22:41:08 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 5 Mar 2021 22:41:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v3]
In-Reply-To: <RrkHIgDAJvTf8YsG5F2Y8mEKRlnJadhb_BB74OZtrmo=.babb71a8-e9a9-4039-88b4-86c8c5f8af5e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
 <RrkHIgDAJvTf8YsG5F2Y8mEKRlnJadhb_BB74OZtrmo=.babb71a8-e9a9-4039-88b4-86c8c5f8af5e@github.com>
Message-ID: <i2LvIKRqjHD1sM4hrRfNGomn8XJPqzAbu5262ASffBQ=.b5406245-c9b0-4594-9555-d02988685234@github.com>

On Fri, 5 Mar 2021 17:21:36 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
>> 
>> Fix:
>> Introduce a new flag to indicate DND operation between Java and native app. 
>> 
>> Testing:
>> mach5 green
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove flag setting from DragOver

Marked as reviewed by aivanov (Reviewer).

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

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

From serb at openjdk.java.net  Fri Mar  5 23:31:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 5 Mar 2021 23:31:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
In-Reply-To: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
References: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
Message-ID: <_I4AJrRT5_BNI9jtP8MTN0O5Kgw7P0DSV2Qd8cdgrMk=.502ac334-001d-4825-96d7-6ea8778a4753@github.com>

On Thu, 4 Mar 2021 21:37:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Root cause:**
> `getPrinterNames()` has two calls to [`::EnumPrinters`](https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters). The first call is to get the required buffer size to contain the structures and any strings. The second call is to get the list of printers.
> 
> Yet the list of printers or the names of printers can change between the two calls. If it happens, the second call to `EnumPrinters` fails but it is not checked.
> 
> I couldn't reproduce the crash myself. However, I reproduced the failure in the second call to `::EnumPrinters` by adding `::Sleep(500)` and by renaming the printers so that the data doesn't fit into the allocated buffer:
> 
> 1: bResult: 0, cbNeeded: 504, cReturned: 0
> 2: bResult: 0, cbNeeded: 512, cReturned: 0
>     !!! error
> 
> During my testing, `cReturned` has always been zero whenever `EnumPrinters` fails.
> 
> The crash dumps show that `cReturned` is non-zero but the `pPrinterEnum` buffer doesn't contain valid data. Reading `info4->pPrinterName` at the line
> utf_str = JNU_NewStringPlatform(env, info4->pPrinterName);
> raises Access Violation exception.
> 
> **The fix:**
> Check the return value of `EnumPrinters` and allow for 5 retries. If the function still returns failure, make sure `cReturned` is set to zero.
> 
> I'm going to close [JDK-6996051](https://bugs.openjdk.java.net/browse/JDK-6996051) and [JDK-8182683](https://bugs.openjdk.java.net/browse/JDK-8182683) reported previously about the same crash as duplicate of the current [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829).
> 
> **Testing:**
> I used [`RemotePrinterStatusRefresh.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java) for testing, it shows the list of currently available printers. In the background I ran `PrinterRename.ps1` PowerShell script which remains a printer, the script is attached to the JBS issue.
> 
> Without the fix, the list of available printers was empty occasionally because `EnumPrinters` returned failure and set `cReturned` to zero. With the fix, the list of printers is always filled.

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Fri Mar  5 23:33:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 5 Mar 2021 23:33:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v3]
In-Reply-To: <RrkHIgDAJvTf8YsG5F2Y8mEKRlnJadhb_BB74OZtrmo=.babb71a8-e9a9-4039-88b4-86c8c5f8af5e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
 <RrkHIgDAJvTf8YsG5F2Y8mEKRlnJadhb_BB74OZtrmo=.babb71a8-e9a9-4039-88b4-86c8c5f8af5e@github.com>
Message-ID: <I9Pb7kFqb9rcGDw8koNs4pWOYiVBqON1_gQwydH3bio=.c5b3c475-7a13-4767-8b36-63b6a13abb7f@github.com>

On Fri, 5 Mar 2021 17:21:36 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
>> 
>> Fix:
>> Introduce a new flag to indicate DND operation between Java and native app. 
>> 
>> Testing:
>> mach5 green
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove flag setting from DragOver

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Sat Mar  6 03:54:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 6 Mar 2021 03:54:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with
 low DPI has bad quality on Windows
In-Reply-To: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
References: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
Message-ID: <jbiiDj9wz7HpsJAQZHsliJcNxO40GjenIBmWuGqjLLE=.3ce99a95-2d74-44c1-8750-c7e2f2e91e0c@github.com>

On Fri, 26 Feb 2021 19:40:22 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
> 
> The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page".
> 
> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
> 
> The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
> 
> I tried to put wPrinterJob.beginPath()/endPath()  methods around wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape.
> 
> The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method.
> The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() .
> 
> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix.
> 
> There are two failed automated tests which fail without the fix as well:
> java/awt/print/PrinterJob/GlyphPositions.java 
> java/awt/print/PrinterJob/PSQuestionMark.java
> 
> The following manual tests have issues on my system:
> - `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static"
> 
> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons.
> 
> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
> 
> 
> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain  print/pass/fail buttons and it is not possible to close the window.
> 
> - The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message:
> java/awt/print/Dialog/DialogOrient.java
> java/awt/print/Dialog/DialogType.java
> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
> java/awt/print/PrinterJob/PageDialogTest.java
> java/awt/print/PrinterJob/PageRanges.java
> java/awt/print/PrinterJob/PageRangesDlgTest.java
> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
> java/awt/print/PrinterJob/PrintLatinCJKTest.java
> java/awt/print/PrinterJob/PrintTextTest.java
> java/awt/print/PrinterJob/SwingUIText.java
> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
> java/awt/PrintJob/SaveDialogTitleTest.java

I'll run the tests for this fix.

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

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

From itakiguchi at openjdk.java.net  Sat Mar  6 05:06:06 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sat, 6 Mar 2021 05:06:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows
In-Reply-To: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
Message-ID: <fmm-D54GwBiWV5cas0oXz6xUuYddXpx-uHGbR2xbcvs=.01ac2e1f-7536-416a-b895-cf0be7f7c75c@github.com>

On Thu, 4 Mar 2021 10:36:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
> 
> Fix:
> Introduce a new flag to indicate DND operation between Java and native app. 
> 
> Testing:
> mach5 green

@dmarkov20 
Sorry I'm not reviewer.
It seems Copyright year is not changed. Is it OK ?

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

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

From kizune at openjdk.java.net  Sat Mar  6 05:11:06 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 6 Mar 2021 05:11:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v3]
In-Reply-To: <RrkHIgDAJvTf8YsG5F2Y8mEKRlnJadhb_BB74OZtrmo=.babb71a8-e9a9-4039-88b4-86c8c5f8af5e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
 <RrkHIgDAJvTf8YsG5F2Y8mEKRlnJadhb_BB74OZtrmo=.babb71a8-e9a9-4039-88b4-86c8c5f8af5e@github.com>
Message-ID: <WugrlXWLA3ARIawjo4kqMX8oCazDT5bQYEbNTC2kF1I=.832501ca-03e0-42c9-b3a3-bab26aab1feb@github.com>

On Fri, 5 Mar 2021 17:21:36 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
>> 
>> Fix:
>> Introduce a new flag to indicate DND operation between Java and native app. 
>> 
>> Testing:
>> mach5 green
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove flag setting from DragOver

Marked as reviewed by kizune (Reviewer).

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

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

From dmarkov at openjdk.java.net  Sat Mar  6 09:25:17 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Sat, 6 Mar 2021 09:25:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows
In-Reply-To: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
Message-ID: <OnDWa7eXLwTVDSDFwz-GbqLoacazF0312sFk0XAVgl0=.1b2858a3-92f2-4f91-8e04-dd2dbb1cadbe@github.com>

On Thu, 4 Mar 2021 10:36:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
> 
> Fix:
> Introduce a new flag to indicate DND operation between Java and native app. 
> 
> Testing:
> mach5 green

> @dmarkov20
> Sorry I'm not reviewer.
> It seems Copyright year is not changed. Is it OK ?

I have updated the copyright

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

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

From dmarkov at openjdk.java.net  Sat Mar  6 09:25:17 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Sat, 6 Mar 2021 09:25:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262446: DragAndDrop hangs on Windows [v4]
In-Reply-To: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
Message-ID: <q7GvRtsRLMah8fSRiFtKafIgKb9AYHGZTyXaY21Fi3w=.108ebbb7-b807-468c-aa08-9485b6252a8a@github.com>

> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
> 
> Fix:
> Introduce a new flag to indicate DND operation between Java and native app. 
> 
> Testing:
> mach5 green

Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2825/files
  - new: https://git.openjdk.java.net/jdk/pull/2825/files/dbc9dac7..3810f1b0

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

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

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

From serb at openjdk.java.net  Sat Mar  6 20:46:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 6 Mar 2021 20:46:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263051: Modernize the code in the
 java.awt.color package
Message-ID: <s7UEtgrVf-FNuc_cU8nwF0GK70G43RRuBf0ixKTtU-k=.8e8a033f-e1ee-4ecc-acae-f06b77924753@github.com>

This is mostly the polish of the different methods in this package.

Most changes are spacing and formatting, plus code simplification. No semantic changes, mach5 is green.

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

Commit messages:
 - Unify theTagSignature vs tagSignature
 - Update ICC_Profile.java
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/2855/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2855&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263051
  Stats: 420 lines in 4 files changed: 9 ins; 255 del; 156 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2855.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2855/head:pull/2855

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Mar  7 19:36:14 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 7 Mar 2021 19:36:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
Message-ID: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>

8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe

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

Commit messages:
 - [PATCH] Thread-safe initialization of SunFontManager.platformFontMap
 - [PATCH] Thread-safe initialization of SunFontManager.platformFontMap

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

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

From serb at openjdk.java.net  Sun Mar  7 19:36:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 7 Mar 2021 19:36:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
Message-ID: <2SZzwUvnnq3F2GQCzylYGwBEUXFlALggO67XbZVtiGU=.5c138090-51cd-4430-af0c-50c4c60ddf23@github.com>

On Sat, 27 Feb 2021 18:33:52 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe

The bug: https://bugs.openjdk.java.net/browse/JDK-8263138

src/java.desktop/share/classes/sun/font/SunFontManager.java line 1452:

> 1450:         if (platformFontMap == null) {
> 1451:             platformFontMap = populateHardcodedFileNameMap();
> 1452:             SunFontManager.platformFontMap = platformFontMap;

I am not sure it is enough for "thread-safe initialization". The "platformFontMap" might not be null, but its content can be broken/incomplete at this point.

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

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

From prr at openjdk.java.net  Sun Mar  7 19:36:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 7 Mar 2021 19:36:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <2SZzwUvnnq3F2GQCzylYGwBEUXFlALggO67XbZVtiGU=.5c138090-51cd-4430-af0c-50c4c60ddf23@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
 <2SZzwUvnnq3F2GQCzylYGwBEUXFlALggO67XbZVtiGU=.5c138090-51cd-4430-af0c-50c4c60ddf23@github.com>
Message-ID: <IiTgaYghYFyXOieTHSrsCXffmVl63I_rxefRYfojz_w=.40e800b6-b68d-467c-b1a4-f47da0c06a60@github.com>

On Sun, 7 Mar 2021 03:32:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe
>
> The bug: https://bugs.openjdk.java.net/browse/JDK-8263138

I don't know why making this volatile is doing anything.
Let's discuss this further.

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

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

From github.com+7806504+liach at openjdk.java.net  Sun Mar  7 19:36:15 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Sun, 7 Mar 2021 19:36:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <2SZzwUvnnq3F2GQCzylYGwBEUXFlALggO67XbZVtiGU=.5c138090-51cd-4430-af0c-50c4c60ddf23@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
 <2SZzwUvnnq3F2GQCzylYGwBEUXFlALggO67XbZVtiGU=.5c138090-51cd-4430-af0c-50c4c60ddf23@github.com>
Message-ID: <ViAlOGgno24j1gAm2mQhNQr1pRlxfIdQeYADrlQkVXc=.e3e586b0-852b-4f2b-b16a-aa04bf202042@github.com>

On Sat, 27 Feb 2021 22:30:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe
>
> src/java.desktop/share/classes/sun/font/SunFontManager.java line 1452:
> 
>> 1450:         if (platformFontMap == null) {
>> 1451:             platformFontMap = populateHardcodedFileNameMap();
>> 1452:             SunFontManager.platformFontMap = platformFontMap;
> 
> I am not sure it is enough for "thread-safe initialization". The "platformFontMap" might not be null, but its content can be broken/incomplete at this point.

https://github.com/openjdk/jdk/pull/2691#issuecomment-784367127

In short, previously platformFontMap references were field set/gets and may be inconsistent due to concurrency. It is now moved to a local variable; also the map modifications have been moved to fields to avoid concurrency issues with hash map as far as I can see.

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

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

From serb at openjdk.java.net  Sun Mar  7 19:36:15 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 7 Mar 2021 19:36:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <ViAlOGgno24j1gAm2mQhNQr1pRlxfIdQeYADrlQkVXc=.e3e586b0-852b-4f2b-b16a-aa04bf202042@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
 <2SZzwUvnnq3F2GQCzylYGwBEUXFlALggO67XbZVtiGU=.5c138090-51cd-4430-af0c-50c4c60ddf23@github.com>
 <ViAlOGgno24j1gAm2mQhNQr1pRlxfIdQeYADrlQkVXc=.e3e586b0-852b-4f2b-b16a-aa04bf202042@github.com>
Message-ID: <DsMe924SFr8MJiZxgDNgMwVB3AGSIcEuQb3rfvkYLT0=.a7235dfa-4ff8-46ce-bf04-d3c3e572f31e@github.com>

On Sun, 28 Feb 2021 03:50:13 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/font/SunFontManager.java line 1452:
>> 
>>> 1450:         if (platformFontMap == null) {
>>> 1451:             platformFontMap = populateHardcodedFileNameMap();
>>> 1452:             SunFontManager.platformFontMap = platformFontMap;
>> 
>> I am not sure it is enough for "thread-safe initialization". The "platformFontMap" might not be null, but its content can be broken/incomplete at this point.
>
> https://github.com/openjdk/jdk/pull/2691#issuecomment-784367127
> 
> In short, previously platformFontMap references were field set/gets and may be inconsistent due to concurrency. It is now moved to a local variable; also the map modifications have been moved to fields to avoid concurrency issues with hash map as far as I can see.

One thread may create the local platformFontMap, then set the static SunFontManager.platformFontMap field, and then initialize the platformFontMap or mix these operations. The second thread may see non-null SunFontManager.platformFontMap which is not still initialized.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Mar  7 19:36:16 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 7 Mar 2021 19:36:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <DsMe924SFr8MJiZxgDNgMwVB3AGSIcEuQb3rfvkYLT0=.a7235dfa-4ff8-46ce-bf04-d3c3e572f31e@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
 <2SZzwUvnnq3F2GQCzylYGwBEUXFlALggO67XbZVtiGU=.5c138090-51cd-4430-af0c-50c4c60ddf23@github.com>
 <ViAlOGgno24j1gAm2mQhNQr1pRlxfIdQeYADrlQkVXc=.e3e586b0-852b-4f2b-b16a-aa04bf202042@github.com>
 <DsMe924SFr8MJiZxgDNgMwVB3AGSIcEuQb3rfvkYLT0=.a7235dfa-4ff8-46ce-bf04-d3c3e572f31e@github.com>
Message-ID: <Iff6XlCM07p0lZCZ0jh-UXSTgPTItEnoiDAxydsFI0U=.a694a485-eda7-4519-9049-dde2856b9762@github.com>

On Sun, 28 Feb 2021 04:56:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> https://github.com/openjdk/jdk/pull/2691#issuecomment-784367127
>> 
>> In short, previously platformFontMap references were field set/gets and may be inconsistent due to concurrency. It is now moved to a local variable; also the map modifications have been moved to fields to avoid concurrency issues with hash map as far as I can see.
>
> One thread may create the local platformFontMap, then set the static SunFontManager.platformFontMap field, and then initialize the platformFontMap or mix these operations. The second thread may see non-null SunFontManager.platformFontMap which is not still initialized.

Made `volatile` to guarantee memory visibility if thread saw non-null value.

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

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

From serb at openjdk.java.net  Sun Mar  7 19:36:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 7 Mar 2021 19:36:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <Iff6XlCM07p0lZCZ0jh-UXSTgPTItEnoiDAxydsFI0U=.a694a485-eda7-4519-9049-dde2856b9762@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
 <2SZzwUvnnq3F2GQCzylYGwBEUXFlALggO67XbZVtiGU=.5c138090-51cd-4430-af0c-50c4c60ddf23@github.com>
 <ViAlOGgno24j1gAm2mQhNQr1pRlxfIdQeYADrlQkVXc=.e3e586b0-852b-4f2b-b16a-aa04bf202042@github.com>
 <DsMe924SFr8MJiZxgDNgMwVB3AGSIcEuQb3rfvkYLT0=.a7235dfa-4ff8-46ce-bf04-d3c3e572f31e@github.com>
 <Iff6XlCM07p0lZCZ0jh-UXSTgPTItEnoiDAxydsFI0U=.a694a485-eda7-4519-9049-dde2856b9762@github.com>
Message-ID: <d3-jkFXl8_VKrIhtiaTQDbG38Wkm8NgLGGRtovUoypE=.2ca44b92-d0be-4021-8f99-17e4d9a8d63f@github.com>

On Sun, 28 Feb 2021 08:47:22 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> One thread may create the local platformFontMap, then set the static SunFontManager.platformFontMap field, and then initialize the platformFontMap or mix these operations. The second thread may see non-null SunFontManager.platformFontMap which is not still initialized.
>
> Made `volatile` to guarantee memory visibility if thread saw non-null value.

I don't have any other questions, will file a bug and run the tests.

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

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

From serb at openjdk.java.net  Sun Mar  7 23:07:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 7 Mar 2021 23:07:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
Message-ID: <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>

On Mon, 1 Mar 2021 11:17:39 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 36 additional commits since the last revision:
> 
>  - Lanai PR#206 - 8262729 - aghaisas
>  - Lanai PR#205 - 8262496 - avu
>  - Lanai PR#203 - 8262313 - jdv
>  - Lanai PR#202 - 8262293 - avu
>  - Lanai PR#201 - 8261891 - avu
>  - Lanai PR#200 - 8262115 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#199 - 8262091 - aghaisas
>  - Lanai PR#198 - 8261646 - avu
>  - Lanai PR#197 - 8261960 - jdv
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/49503c0d...5cb1fd91

src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 81:

> 79:                 // Try falling back to OpenGL pipeline
> 80:                 if (MacOSFlags.isMetalVerbose()) {
> 81:                     System.out.println("Metal rendering pipeline initialization failed. Using OpenGL rendering pipeline.");

Please split the long lines, here and there. Most of these files use 80 chars per line.

src/java.desktop/macosx/classes/sun/java2d/metal/MTLBlitLoops.java line 499:

> 497:         }
> 498: 
> 499:         // We can convert argb_pre data from MTL surface in two places:

Does anybody check that this is true for the metal pipeline? or It is just copied from the OGL?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 58:

> 56:      * Makes the given GraphicsConfig's context current to its associated
> 57:      * "scratch surface".  Each GraphicsConfig maintains a native context
> 58:      * (MTLDevice) as well as a native pbuffer

"pbuffer"?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 68:

> 66:      * when disposing a texture-based surface).
> 67:      */
> 68:     public static void setScratchSurface(long pConfigInfo) {

How the scratch surface is used in the metal pipeline? Why it is not enough to set the "context current"?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 168:

> 166:         }
> 167: 
> 168:         ContextCapabilities caps = new MTLContext.MTLContextCaps(

CAPS_DOUBLEBUFFERED is not included?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 140:

> 138:             StringBuilder sb = new StringBuilder(super.toString());
> 139:             if ((caps & CAPS_DOUBLEBUFFERED) != 0) {
> 140:                 sb.append("CAPS_DOUBLEBUFFERED|");

Related to other questions, we do not include CAPS_DOUBLEBUFFERED, but anyway, report the surface as double buffered.

src/java.desktop/macosx/classes/sun/java2d/metal/MTLLayer.java line 44:

> 42: 
> 43:     // Pass the insets to native code to make adjustments in blitTexture
> 44:     private static native void nativeSetInsets(long layerPtr, int top, int left);

Probably I have asked this already, but why we need to use insets? Why insets is not necessary for ogl?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderer.java line 25:

> 23:  * questions.
> 24:  */
> 25: package sun.java2d.metal;

Looks like other files use blank line befor "package".

src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 146:

> 144:                 return MTLSurfaceRTT;
> 145:             default:
> 146:                 return MTLSurface;

Do we really support 3 different types of surface? I guess only two of them are different: textures used for manageable images, and surfaces used by the volatile image.

src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 194:

> 192:      * Creates a SurfaceData object representing an off-screen buffer
> 193:      */
> 194:     public static MTLOffScreenSurfaceData createData(MTLGraphicsConfig gc,

Something wrong in the formatting.

src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 221:

> 219:     protected native boolean initRTexture(long pData, boolean isOpaque, int width, int height);
> 220: 
> 221:     protected native boolean initFlipBackbuffer(long pData);

flip back buffer is supported?

src/java.desktop/macosx/classes/sun/lwawt/macosx/CWarningWindow.java line 304:

> 302:                 };
> 303:             }
> 304:             public MTLLayer createMTLLayer() {

TODO to test that this functionality works

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 36:

> 34: #include "GraphicsPrimitiveMgr.h"
> 35: 
> 36: #include <stdlib.h> // malloc

malloc is unused in this file?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 676:

> 674:             height = srcInfo.bounds.y2 - srcInfo.bounds.y1;
> 675: 
> 676:             pDst = PtrAddBytes(pDst, dstx * dstInfo.pixelStride);

Here and in other places use the PtrPixelsRow instead, do not use multiplication, see the history of the OGLBlitLoops_SurfaceToSwBlit method.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceData.m line 284:

> 282:  */
> 283: jboolean
> 284: MTLSD_InitMTLWindow(JNIEnv *env, BMTLSDOps *bmtlsdo)

When the MTLWindow is used?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceData.m line 316:

> 314: 
> 315: void
> 316: MTLSD_SwapBuffers(JNIEnv *env, jlong pPeerData)

Copied from OGL and can be removed?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h line 109:

> 107: #define MTLSD_TEXTURE         sun_java2d_pipe_hw_AccelSurface_TEXTURE
> 108: #define MTLSD_FLIP_BACKBUFFER sun_java2d_pipe_hw_AccelSurface_FLIP_BACKBUFFER
> 109: #define MTLSD_RT_TEXTURE        sun_java2d_pipe_hw_AccelSurface_RT_TEXTURE

Only two of them are supported? MTLSD_TEXTURE and MTLSD_RT_TEXTURE?

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

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

From serb at openjdk.java.net  Sun Mar  7 23:07:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 7 Mar 2021 23:07:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <8YBuOeDAPN2osBnW5cyN-91hYtg7malBqDlJZsgWrPk=.6c99ab50-76a8-4686-85dd-5918abfdacf0@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <8YBuOeDAPN2osBnW5cyN-91hYtg7malBqDlJZsgWrPk=.6c99ab50-76a8-4686-85dd-5918abfdacf0@github.com>
Message-ID: <J1-dSmk1I83VAmaOAcG5ETCGSud-NK807s1squvqMMA=.08f5e156-d92d-4fc2-945f-4f3b89d9624f@github.com>

On Fri, 5 Feb 2021 22:00:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas 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 36 additional commits since the last revision:
>> 
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - Lanai PR#205 - 8262496 - avu
>>  - Lanai PR#203 - 8262313 - jdv
>>  - Lanai PR#202 - 8262293 - avu
>>  - Lanai PR#201 - 8261891 - avu
>>  - Lanai PR#200 - 8262115 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#199 - 8262091 - aghaisas
>>  - Lanai PR#198 - 8261646 - avu
>>  - Lanai PR#197 - 8261960 - jdv
>>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/f34bb8ed...5cb1fd91
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 82:
> 
>> 80:     (JNIEnv *env, jclass mtlgc)
>> 81: {
>> 82:     FILE *f = popen("/usr/sbin/system_profiler SPDisplaysDataType", "r");
> 
> How robust is this? It seems like the contents of this could be an implementation detail and subject to change. Is it documented by Apple?

I suggest fixing this before the integration.

> test/jdk/performance/client/RenderPerfTest/Makefile line 10:
> 
>> 8: #   - Redistributions of source code must retain the above copyright
>> 9: #     notice, this list of conditions and the following disclaimer.
>> 10: #
> 
> As mentioned in the preliminary review, this file and `build.xml` have a BSD copyright. I think that should be GPLv2 (without classpath exception since this is a test).

Probably place it near J2Dbench?

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

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

From Sergey.Bylokhov at oracle.com  Mon Mar  8 04:59:58 2021
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 7 Mar 2021 20:59:58 -0800
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
 OpenJDK
In-Reply-To: <CAKjRUT7ALdjKA5ZvdO8LV3_cGAOTBRtjZu7xQ9zcccPfPdBb8w@mail.gmail.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com> <5BB69B8A.3040106@oracle.com>
 <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
 <CALLYd6TgJxnisWrtKWFAn58nGe6_DD4vdM-iByeGwNTqSL6dnA@mail.gmail.com>
 <5BB6F64F.2080303@oracle.com>
 <CALLYd6TigE9vg9N8EkwfosyDOgwh3va++ZVmOJ5w67PrfJMMzQ@mail.gmail.com>
 <5BB6FF4A.3090105@oracle.com>
 <CAKjRUT7ALdjKA5ZvdO8LV3_cGAOTBRtjZu7xQ9zcccPfPdBb8w@mail.gmail.com>
Message-ID: <6b7208d7-a528-882e-8f5a-920539c2b8ae@oracle.com>

Hi, Laurent.

On 04.10.2018 23:45, Laurent Bourg?s wrote:
> I looks like a call to let me have a look. Maybe I could inspect what makes LCMS slow (lerp?) ... and optimize the C code or at least tune gcc options.

Did you have a chance to look at it? =)


> I would not make MT in lcms as it can affect MT in java.
> Maybe PDFImage could convert tiles instead of the all image ?
> 
> Anyway I will publish my lknux perf report showing time spent in kcms / lcms asap.
> 
> PS: I tested OpenJDK8 and perf is on par with OpenJDK9.
> 
> Laurent
> 
> 
> 
>     On 10/4/18, 10:47 PM, Daniel Persson wrote:
>>     Hi Phil.
>>
>>     Well it seems like you've been in this discussion before
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8041125 <https://bugs.openjdk.java.net/browse/JDK-8041125>
>>
>>     Wasn't aware that PDFBox PDF2Image used the Kcms Provider per default.
>>     You may close this issue as we have figured out the reason.
>>
>>     Best regards
>>     Daniel
>>
>>     On Fri, Oct 5, 2018 at 7:27 AM Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>
>>
>>
>>         On 10/4/18, 10:22 PM, Daniel Persson wrote:
>>>         Hi Laurent
>>>
>>>         Well that seems like a reasonable assumption.
>>>
>>>         https://github.com/kalaspuffar/ColorConvTest/blob/master/KCMSTest.md <https://github.com/kalaspuffar/ColorConvTest/blob/master/KCMSTest.md>
>>>
>>>         The test with a "blank" image has a 1 seconds difference.
>>>
>>>         And the test with an image from the PDF in question have a 52 seconds difference.
>>
>>         I tried playing with different image data but I didn't see a sensitivity to that.
>>         Maybe I needed to try something more complex.
>>>
>>>         So why don't OpenJDK 9 and forward have KcmsServiceProvider bundled?
>>>         Does this provider make a worse result on the image?
>>>
>>         It is not open source. It cannot be part of OpenJDK. Ever.
>>         And see my other email for the other reasons.
>>         So there is no quick or easy solution.
>>
>>         FWIW the #1 reason I left KCMS in Oracle 8 and even 9 was because of the MT performance
>>         issue, but as we now converge Oracle JDK & OpenJDK that was a non-starter and it was
>>         removed along with other closed source components.
>>
>>         -phil.
>>
>>>         Best regards
>>>         Daniel
>>>
>>>
>>>
>>>
>>>         On Fri, Oct 5, 2018 at 6:55 AM Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>>>
>>>             Phil,
>>>             I just gg a bit and got the PDFImage source:
>>>
>>>             public static void main( String[] args ) throws IOException
>>>             79 ? ? {
>>>             80 try
>>>             81 {
>>>             82 ? ? // force KCMS (faster than LCMS) if available
>>>             83 Class.forName("sun.java2d.cmm.kcms.KcmsServiceProvider");
>>>             84 ? ? System.setProperty("sun.java2d.cmm", "sun.java2d.cmm.kcms.KcmsServiceProvider");
>>>             85 }
>>>             86 catch (ClassNotFoundException e)
>>>             87 {
>>>             88 ? ? LOG.debug("KCMS service not found - using LCMS", e);
>>>             89 }
>>>             90
>>>
>>>             https://svn.apache.org/viewvc/pdfbox/trunk/tools/src/main/java/org/apache/pdfbox/tools/PDFToImage.java?revision=1829374&view=markup <https://svn.apache.org/viewvc/pdfbox/trunk/tools/src/main/java/org/apache/pdfbox/tools/PDFToImage.java?revision=1829374&view=markup>
>>>
>>>             That's all folks !
>>>
>>>             Le ven. 5 oct. 2018 ? 01:00, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> a ?crit?:
>>>
>>>                 Yep. LCMS is the default in 8u.
>>>
>>>                 And although KCMS is a lot faster? on my CConv test ...
>>>
>>>                 ~/jdk8u181/bin/java CConv
>>>                 13289
>>>
>>>                 ?~/jdk8u181/bin/java -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider CConv
>>>                 5131
>>>
>>>
>>>                 It makes no difference on the pdf conversion :
>>>
>>>                 ~/jdk8u181/bin/java -jar pdfbox-app-2.0.11.jar PDFToImage? -time test.pdf Rendered 1 page in 4985ms
>>>
>>>                 ~/jdk8u181/bin/java -Dsun.java2d.cmm=sun.java2d.cmm.kcms.KcmsServiceProvider -jar pdfbox-app-2.0.11.jar PDFToImage? -time test.pdf
>>>                 Rendered 1 page in 4723ms
>>>
>>>
>>>                 Note: KCMS maybe faster on CConv but it has no support for modern ICC profiles
>>>                 and I haven't checked if it is even applying the pdfbox one properly.
>>>                 But it does have support to split a job into concurrent tasks for sub-images
>>>                 which can help on the larger images like the one I am using in CConv.
>>>
>>>                 -phil.
>>>
>>>                 On 10/4/18, 2:24 PM, Philip Race wrote:
>>>>                 I might be losing it, but I am 99% sure that LCMS is the color conversion engine in 8.
>>>>                 KCMS was there only for backup. You'd have to know the magic flag to get it and
>>>>                 no one has said anything to the effect that they are using it.
>>>>
>>>>                 -phil.
>>>>
>>>>                 On 10/4/18, 11:33 AM, Laurent Bourg?s wrote:
>>>>>                 Phil,
>>>>>                 I wondered if ang RenderingHint defaults changed since 8...
>>>>>
>>>>>                 Moreover I started playing with linux perf + jit agent and it is easy than before wigh oprofile + jvmtiagent.
>>>>>
>>>>>                 I noticed that OracleJDK8 uses KCMS and OpenJDK11 uses LCMS for color conversion as does OpenJDK8, that could explain the performance gap.
>>>>>
>>>>>                 Finally PDFImage test is run only once so the overhead may come from warmup (jit, g1)...
>>>>>
>>>>>                 More later,
>>>>>                 Laurent
>>>>>
>>>>>                 Le jeu. 4 oct. 2018 ? 20:03, Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> a ?crit?:
>>>>>
>>>>>
>>>>>
>>>>>                     On 10/03/2018 11:58 PM, Laurent Bourg?s wrote:
>>>>>>                     Hi,
>>>>>>                     I will get the code and add debugging logs: env & system properties and java2d RenderingHints.
>>>>>
>>>>>                     The code in pdfbox passes null for the hints. So there should be no difference attributable to that.
>>>>>
>>>>>                     -phil.
>>>>>>
>>>>>>                     I suspect these hints are different or have a noticiable impact: color interpolation & rendering quality.
>>>>>>
>>>>>>                     I suppose the backend corresponds to software loops but some 2d operations can be accelerated ?
>>>>>>
>>>>>>                     Anyway I will push any change in the code.
>>>>>>
>>>>>>                     PS: I can run linux perf to profile both java & native code....
>>>>>>
>>>>>>                     Cheers,
>>>>>>                     Laurent
>>>>>>
>>>>>>                     Le jeu. 4 oct. 2018 ? 07:50, Daniel Persson <mailto.woden at gmail.com <mailto:mailto.woden at gmail.com>> a ?crit?:
>>>>>>
>>>>>>                         Hi Philip and Laurent.
>>>>>>
>>>>>>                         I've talked with Tilman and Andreas from the PDFBox team and they see similar connections to the ColorConvertOp filter but wanted to try with one of the images of the PDF as a raster.
>>>>>>
>>>>>>                         As we try different things I thought it good for collaboration to create a repository with the code so all can contribute.
>>>>>>
>>>>>>                         https://github.com/kalaspuffar/ColorConvTest <https://github.com/kalaspuffar/ColorConvTest>
>>>>>>
>>>>>>                         I've run the 3 different tests on my Machine (Thinkpad P51s) with custom Gentoo installed, if important to the conversation.
>>>>>>
>>>>>>                         I tried to invite you all as collaborators to this repository if you think this is a bad Idea let me know.
>>>>>>
>>>>>>                         Best?regards
>>>>>>                         Daniel
>>>>>>
>>>>>>                         On Wed, Oct 3, 2018 at 7:51 PM Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>>>>>>
>>>>>>                             Very good job, phil.
>>>>>>
>>>>>>                             I will try your CCONV test on my linux machine to see if it is platform dependent ... or hw ?
>>>>>>
>>>>>>                             Laurent
>>>>>>
>>>>>>                             Le mer. 3 oct. 2018 ? 19:19, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> a ?crit?:
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 On 10/3/18, 1:15 AM, Laurent Bourg?s wrote:
>>>>>>>                                 Phil,
>>>>>>>
>>>>>>>                                 If you look at the given pdf file, it has large images that exceed 2k so such ones may be more costly to convert.
>>>>>>
>>>>>>                                 FWIW the one I profiled was by far the largest at 2577x1540.
>>>>>>                                 The rest are more like 100x100, 200x200 or 500x500 - all approximations.
>>>>>>>
>>>>>>>                                 As jpeg decoder in openjdk11 is different than oraclejdk8, it may cause more ColorConvertOp filter operations ... if color profiles are different.
>>>>>>
>>>>>>                                 That doesn't seem likely and in fact since I? instrumented ColorConvertOp in 8 & 11,? I know exactly how many times it was invoked
>>>>>>                                 by pdfbox, (11 times in both cases) and that all the image data is the same. SRC and DEST are the same types etc.
>>>>>>
>>>>>>                                 Also the version of LCMS is the same in 8 and 11 (v2.9).
>>>>>>
>>>>>>                                 -phil
>>>>>>>
>>>>>>>                                 Anyway this performance is not related to Marlin renderer, so I can not help much except in its diagnostic.
>>>>>>>
>>>>>>>                                 Cheers,
>>>>>>>                                 Laurent
>>>>>>>
>>>>>>>                                 Le mar. 2 oct. 2018 ? 23:35, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> a ?crit?:
>>>>>>>
>>>>>>>                                     I've spent some time examining what pdfbox is passing to ColorConvertOp
>>>>>>>                                     It is called about 10 or 11 times in this test with images typically 1-2K in each dimension.
>>>>>>>                                     The input image is a Custom BufferedImage which uses an ICC_ColorSpace constructed
>>>>>>>                                     from a color profile file that is embedded in pdfbox which is an open source equivalent
>>>>>>>                                     of what Acrobat uses. It has a 4 component raster and is opaque
>>>>>>>
>>>>>>>                                     This is filtered into a 3 component standard INT_RGB ColorModel.
>>>>>>>
>>>>>>>                                     I've distilled this down into a small program which has an copy of the method
>>>>>>>                                     that is defined in pdfbox and is invoking the supposedly slow ColorConvertOp.
>>>>>>>
>>>>>>>                                     So I believe this is all exactly what is happening in pdfbox.
>>>>>>>
>>>>>>>                                     What I find is that it is actually much faster on JDK11 than JDK 8.
>>>>>>>
>>>>>>>                                     prrubuntu:~$ ~/jdk-11/bin/java CConv
>>>>>>>                                     4881
>>>>>>>                                     prrubuntu:~$ ~/jdk8u181/bin/java CConv
>>>>>>>                                     12529
>>>>>>>
>>>>>>>
>>>>>>>                                     I can't say why that would be but the results are clear.
>>>>>>>                                     So I am left to suppose that pdfbox really is doing something different in 8 vs 11.
>>>>>>>                                     Or that this not the real problem. What do others see ?
>>>>>>>
>>>>>>>                                     I've attached the program. The 1Mb color profile file can be got from the pdfbox sources.
>>>>>>>
>>>>>>>                                     -phil.
>>>>>>>
>>>>>>>
>>>>>>>                                     On 10/2/18, 9:35 AM, Laurent Bourg?s wrote:
>>>>>>>>                                     Hi Daniel,
>>>>>>>>
>>>>>>>>
>>>>>>>>                                         Let's not compare apples and oranges. What I can see it takes the same route and behave?similarly.
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     ?I agree, I did not take enough time to get accurate profiles, sorry.
>>>>>>>>
>>>>>>>>
>>>>>>>>                                         If you look at
>>>>>>>>                                         http://uhash.com/java_reg/Call_Tree_java_8.html <http://uhash.com/java_reg/Call_Tree_java_8.html>
>>>>>>>>                                         http://uhash.com/java_reg/Call_Tree_java_11.html <http://uhash.com/java_reg/Call_Tree_java_11.html>
>>>>>>>>
>>>>>>>>                                         You can see that ConvertOp.filter takes 1.5s longer on Java 11.
>>>>>>>>
>>>>>>>>
>>>>>>>>                                     I confirm: 1.8s vs 300ms.
>>>>>>>>
>>>>>>>>                                     Philip, do you know what could have change in this 2d area ?
>>>>>>>>
>>>>>>>>                                     I imagine ColorConvertOp delegates to native code so color profile (ICC) or hidpi support may have an impact here (or just compiler options may be different) ...
>>>>>>>>
>>>>>>>>                                     If needed, I could profile native code using oprofile / perf.
>>>>>>>>
>>>>>>>>                                     Laurent
>>>>>>>
>>>>>


-- 
Best regards, Sergey.

From aghaisas at openjdk.java.net  Mon Mar  8 08:06:03 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 8 Mar 2021 08:06:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v11]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <3XzbfpM41bmyAd3DCXAqrSEJaFlA5-CCd9PUO5fKpD8=.88284596-8b8d-48eb-bf69-6ef5c3f55037@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

Ajit Ghaisas 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 41 additional commits since the last revision:

 - Lanai PR#210 - 8263159 - jdv
 - Lanai PR#209 - 8262936 - jdv
 - Lanai PR#208 - 8262928 - jdv
 - Lanai PR#207 - 8262750 - jdv
 - Merge branch 'master' into 8260931_lanai_JEP_branch
 - Lanai PR#206 - 8262729 - aghaisas
 - Lanai PR#205 - 8262496 - avu
 - Lanai PR#203 - 8262313 - jdv
 - Lanai PR#202 - 8262293 - avu
 - Lanai PR#201 - 8261891 - avu
 - ... and 31 more: https://git.openjdk.java.net/jdk/compare/582d72a8...de456939

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/5cb1fd91..de456939

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=09-10

  Stats: 8128 lines in 291 files changed: 5147 ins; 1823 del; 1158 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

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

From azvegint at openjdk.java.net  Mon Mar  8 13:14:06 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 8 Mar 2021 13:14:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263051: Modernize the code in the
 java.awt.color package
In-Reply-To: <s7UEtgrVf-FNuc_cU8nwF0GK70G43RRuBf0ixKTtU-k=.8e8a033f-e1ee-4ecc-acae-f06b77924753@github.com>
References: <s7UEtgrVf-FNuc_cU8nwF0GK70G43RRuBf0ixKTtU-k=.8e8a033f-e1ee-4ecc-acae-f06b77924753@github.com>
Message-ID: <8XzFmI1kMxV_QwfYYiEa6pDqz6Ovb68K7ZPd4Sqsogw=.b8cc005e-93df-4f25-b396-5b95ae8ffc40@github.com>

On Sat, 6 Mar 2021 03:26:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is mostly the polish of the different methods in this package.
> 
> Most changes are spacing and formatting, plus code simplification. No semantic changes, mach5 is green.

Marked as reviewed by azvegint (Reviewer).

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

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

From kizune at openjdk.java.net  Mon Mar  8 13:27:28 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 8 Mar 2021 13:27:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons
In-Reply-To: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
References: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
Message-ID: <Xj2xcoi5vCQg0gxZizxxEvomvz32LRd6DbBdwqOa1yA=.f677bea5-7cb5-4ce8-85e8-e53c63162bf2@github.com>

On Mon, 8 Mar 2021 13:22:07 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Fix updated after first round of review.

Continuation of review at https://github.com/openjdk/jdk/pull/380

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

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

From kizune at openjdk.java.net  Mon Mar  8 13:27:28 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 8 Mar 2021 13:27:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons
Message-ID: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>

Fix updated after first round of review.

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

Commit messages:
 - 8182043: Access to Windows Large Icons

Changes: https://git.openjdk.java.net/jdk/pull/2875/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8182043
  Stats: 335 lines in 6 files changed: 270 ins; 29 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2875.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875

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

From dmarkov at openjdk.java.net  Mon Mar  8 16:43:07 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Mon, 8 Mar 2021 16:43:07 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8262446: DragAndDrop hangs on Windows
In-Reply-To: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
References: <jcvnd-VQpSyTI3qIePvS62-Q14qLFFgnfJkJonD0S44=.dfda30d7-6f48-4a6e-8230-eb7ac6e2881e@github.com>
Message-ID: <Yvyk0aVeKNXhCAU_EOaPNsyrNOPP7DlMewyX3LUPv1I=.afa16814-86e2-476b-a217-df82b3e810a4@github.com>

On Thu, 4 Mar 2021 10:36:56 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The flag works properly if the DND is performed between two Java windows. However if anything is dragged from native app, (e.g. Windows FileExplorer) to Java the flag is NOT set. That?s the root cause of the hang.
> 
> Fix:
> Introduce a new flag to indicate DND operation between Java and native app. 
> 
> Testing:
> mach5 green

This pull request has now been integrated.

Changeset: bf9b74d1
Author:    Dmitry Markov <dmarkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bf9b74d1
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8262446: DragAndDrop hangs on Windows

Reviewed-by: aivanov, serb, kizune

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar  9 01:40:07 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 9 Mar 2021 01:40:07 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8262161: Refactor manual I/O stream
 copying in java.desktop to use new convenience APIs
In-Reply-To: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
Message-ID: <-jLk_NzWGP-TyHwzQnXyexoqtktQBH3wUO52Fx6XlHc=.9c023cb6-db0f-429c-abbd-d565db439826@github.com>

On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
> 1. java.io.InputStream#readAllBytes
> 2. java.io.InputStream#transferTo
> 3. java.nio.file.Files#copy

This pull request has now been integrated.

Changeset: 39b11138
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/39b11138
Stats:     134 lines in 11 files changed: 3 ins; 102 del; 29 mod

8262161: Refactor manual I/O stream copying in java.desktop to use new convenience APIs

Reviewed-by: serb, prr

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

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

From serb at openjdk.java.net  Tue Mar  9 06:14:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Mar 2021 06:14:07 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263051: Modernize the code in the
 java.awt.color package
In-Reply-To: <s7UEtgrVf-FNuc_cU8nwF0GK70G43RRuBf0ixKTtU-k=.8e8a033f-e1ee-4ecc-acae-f06b77924753@github.com>
References: <s7UEtgrVf-FNuc_cU8nwF0GK70G43RRuBf0ixKTtU-k=.8e8a033f-e1ee-4ecc-acae-f06b77924753@github.com>
Message-ID: <8RtC5E5PKR3yXNL_HGeua6483YxtQFdMeT_zYvtSdHA=.48c5342a-05f8-435a-8f66-bd5b6708ad4a@github.com>

On Sat, 6 Mar 2021 03:26:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is mostly the polish of the different methods in this package.
> 
> Most changes are spacing and formatting, plus code simplification. No semantic changes, mach5 is green.

This pull request has now been integrated.

Changeset: 5bfc5fd3
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5bfc5fd3
Stats:     420 lines in 4 files changed: 9 ins; 255 del; 156 mod

8263051: Modernize the code in the java.awt.color package

Reviewed-by: azvegint

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

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

From aivanov at openjdk.java.net  Tue Mar  9 11:39:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Mar 2021 11:39:07 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8262829: Native crash in
 Win32PrintServiceLookup.getAllPrinterNames()
In-Reply-To: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
References: <_cLbmezA8NPc15e7YAOJxL1rGEfoybdYwYGw306qggg=.0147c018-53eb-460c-8c14-e8f7e71ff150@github.com>
Message-ID: <d-q7-jgiHc6NY4Hi25X3C2eLe0Go4zq6N8974hx8AJ0=.0c904535-1846-48bd-8def-7a95d86043f8@github.com>

On Thu, 4 Mar 2021 21:37:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Root cause:**
> `getPrinterNames()` has two calls to [`::EnumPrinters`](https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters). The first call is to get the required buffer size to contain the structures and any strings. The second call is to get the list of printers.
> 
> Yet the list of printers or the names of printers can change between the two calls. If it happens, the second call to `EnumPrinters` fails but it is not checked.
> 
> I couldn't reproduce the crash myself. However, I reproduced the failure in the second call to `::EnumPrinters` by adding `::Sleep(500)` and by renaming the printers so that the data doesn't fit into the allocated buffer:
> 
> 1: bResult: 0, cbNeeded: 504, cReturned: 0
> 2: bResult: 0, cbNeeded: 512, cReturned: 0
>     !!! error
> 
> During my testing, `cReturned` has always been zero whenever `EnumPrinters` fails.
> 
> The crash dumps show that `cReturned` is non-zero but the `pPrinterEnum` buffer doesn't contain valid data. Reading `info4->pPrinterName` at the line
> utf_str = JNU_NewStringPlatform(env, info4->pPrinterName);
> raises Access Violation exception.
> 
> **The fix:**
> Check the return value of `EnumPrinters` and allow for 5 retries. If the function still returns failure, make sure `cReturned` is set to zero.
> 
> I'm going to close [JDK-6996051](https://bugs.openjdk.java.net/browse/JDK-6996051) and [JDK-8182683](https://bugs.openjdk.java.net/browse/JDK-8182683) reported previously about the same crash as duplicate of the current [JDK-8262829](https://bugs.openjdk.java.net/browse/JDK-8262829).
> 
> **Testing:**
> I used [`RemotePrinterStatusRefresh.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java) for testing, it shows the list of currently available printers. In the background I ran `PrinterRename.ps1` PowerShell script which remains a printer, the script is attached to the JBS issue.
> 
> Without the fix, the list of available printers was empty occasionally because `EnumPrinters` returned failure and set `cReturned` to zero. With the fix, the list of printers is always filled.

This pull request has now been integrated.

Changeset: a6e34b3d
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6e34b3d
Stats:     20 lines in 1 file changed: 13 ins; 0 del; 7 mod

8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames()

Reviewed-by: prr, psadhukhan, serb

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

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

From akozlov at openjdk.java.net  Tue Mar  9 16:12:36 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 16:12:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v24]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:

 - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
 - workaround JDK-8262895 by disabling subtest
 - Fix typo
 - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
 - JDK-8259937: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Fix after JDK-8259539, partially revert preconditions
 - JDK-8260471: bsd_aarch64 part
 - JDK-8259539: bsd_aarch64 part
 - JDK-8257828: bsd_aarch64 part
 - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=23
  Stats: 2873 lines in 73 files changed: 2787 ins; 27 del; 59 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From akozlov at openjdk.java.net  Tue Mar  9 16:12:37 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 16:12:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v12]
In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
Message-ID: <yi2biGsqSXqJPSCRZcsTxv1vVOnSZiGvtBK96gl6u14=.80dd4aa2-e6d1-49aa-a95a-020203b6fce5@github.com>

On Tue, 9 Feb 2021 09:06:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update signal handler part for debugger
>
> src/hotspot/share/runtime/threadWXSetters.hpp line 28:
> 
>> 26: #define SHARE_RUNTIME_THREADWXSETTERS_HPP
>> 27: 
>> 28: #include "runtime/thread.inline.hpp"
> 
> This breaks against our convention to forbid inline.hpp files from being included from being included from .hpp files. You need to rework this by either moving the implementation to a .cpp file, or convert this file into an .inline.hpp
> 
> See the Source Files section in:
> https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html

Thanks, I renamed the file to threadWXSetters.inline.hpp

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

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

From akozlov at openjdk.java.net  Tue Mar  9 16:58:19 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 16:58:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v12]
In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
Message-ID: <z9mnfpAEpe9fRFn8A_rmjYx3nU1mzbRsCiMPWsLEKkU=.b7a08d2b-fc4b-42a6-aabb-2b008427ba2c@github.com>

On Tue, 9 Feb 2021 09:12:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update signal handler part for debugger
>
> src/hotspot/share/runtime/thread.hpp line 848:
> 
>> 846:   void init_wx();
>> 847:   WXMode enable_wx(WXMode new_state);
>> 848: #endif // __APPLE__ && AARCH64
> 
> Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions.

The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. 

In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR.

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

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

From avu at openjdk.java.net  Tue Mar  9 17:29:19 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 9 Mar 2021 17:29:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
Message-ID: <UQKFvwFicbVArPUl_E-mvmRhoRbIrE6BsyP9AN6MJkQ=.efa4917f-dff3-4ce8-8bcc-4e841e86020d@github.com>

On Sun, 7 Mar 2021 22:24:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 36 additional commits since the last revision:
>> 
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - Lanai PR#205 - 8262496 - avu
>>  - Lanai PR#203 - 8262313 - jdv
>>  - Lanai PR#202 - 8262293 - avu
>>  - Lanai PR#201 - 8261891 - avu
>>  - Lanai PR#200 - 8262115 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#199 - 8262091 - aghaisas
>>  - Lanai PR#198 - 8261646 - avu
>>  - Lanai PR#197 - 8261960 - jdv
>>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/ffb3d48c...5cb1fd91
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 68:
> 
>> 66:      * when disposing a texture-based surface).
>> 67:      */
>> 68:     public static void setScratchSurface(long pConfigInfo) {
> 
> How the scratch surface is used in the metal pipeline? Why it is not enough to set the "context current"?

In fact, we don't have any scratch surfaces. SET_SCRATCH_SURFACE effectively sets the new context. For better readability, we should add the new op SET_CONTEXT in BufferedOpCodes

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

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

From avu at openjdk.java.net  Tue Mar  9 17:33:24 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 9 Mar 2021 17:33:24 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
Message-ID: <-5I5uYhE9NCERNocgh3oBFzPxScyu2Una6NkCBfc9tA=.79311ac7-d4e4-407f-bc1a-95e088730b83@github.com>

On Sun, 7 Mar 2021 22:29:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 36 additional commits since the last revision:
>> 
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - Lanai PR#205 - 8262496 - avu
>>  - Lanai PR#203 - 8262313 - jdv
>>  - Lanai PR#202 - 8262293 - avu
>>  - Lanai PR#201 - 8261891 - avu
>>  - Lanai PR#200 - 8262115 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#199 - 8262091 - aghaisas
>>  - Lanai PR#198 - 8261646 - avu
>>  - Lanai PR#197 - 8261960 - jdv
>>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/69ed64f1...5cb1fd91
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 140:
> 
>> 138:             StringBuilder sb = new StringBuilder(super.toString());
>> 139:             if ((caps & CAPS_DOUBLEBUFFERED) != 0) {
>> 140:                 sb.append("CAPS_DOUBLEBUFFERED|");
> 
> Related to other questions, we do not include CAPS_DOUBLEBUFFERED, but anyway, report the surface as double buffered.

We can remove all the unused constants

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

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

From akozlov at openjdk.java.net  Tue Mar  9 17:58:21 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 17:58:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v12]
In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
Message-ID: <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>

On Tue, 9 Feb 2021 09:23:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update signal handler part for debugger
>
> src/hotspot/share/runtime/thread.cpp line 2515:
> 
>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) {
>> 2514:   // Enable WXWrite: called directly from interpreter native wrapper.
>> 2515:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread));
> 
> FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version:
> ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) {
>   MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {}
> void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp)
> With that said, I'm fine with taking this discussion as a follow-up.

The former version used no such macros. I like that now it's clear the W^X management is relevant to macos/aarch64 only. I see the point to move the pre-processor condition into the class implementation. But I think it will bring a bit of inconsistency, as the rest of W^X implementation is explicitly guarded by preprocessor conditionals. I've also tried to push macro conditionals as far as possible down to implementation, providing a kind of generalized W^X interface. That required a few artificial decisions, e.g. how would we call the mode we execute on the rest of platforms with write and execute allowed, WXWriteExec?.. I abandoned that attempt.

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

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

From akozlov at openjdk.java.net  Tue Mar  9 18:04:19 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 18:04:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v21]
In-Reply-To: <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
 <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
Message-ID: <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>

On Mon, 1 Mar 2021 10:31:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Minor fixes
>
> src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:
> 
>> 60: 
>> 61: #if defined(__APPLE__) || defined(_WIN64)
>> 62: #define R18_RESERVED
> 
> #define R18_RESERVED true```

We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?

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

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

From prr at openjdk.java.net  Tue Mar  9 19:57:37 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 9 Mar 2021 19:57:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v11]
In-Reply-To: <3XzbfpM41bmyAd3DCXAqrSEJaFlA5-CCd9PUO5fKpD8=.88284596-8b8d-48eb-bf69-6ef5c3f55037@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <3XzbfpM41bmyAd3DCXAqrSEJaFlA5-CCd9PUO5fKpD8=.88284596-8b8d-48eb-bf69-6ef5c3f55037@github.com>
Message-ID: <hq4fQO_D6x4pPr2pI3EEM5Vh72eAkJV4zaORHcjESTc=.a49415b8-83c9-4e8d-a08f-afdeab6621fa@github.com>

On Mon, 8 Mar 2021 08:06:03 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 41 additional commits since the last revision:
> 
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#206 - 8262729 - aghaisas
>  - Lanai PR#205 - 8262496 - avu
>  - Lanai PR#203 - 8262313 - jdv
>  - Lanai PR#202 - 8262293 - avu
>  - Lanai PR#201 - 8261891 - avu
>  - ... and 31 more: https://git.openjdk.java.net/jdk/compare/32b236e4...de456939

test/jdk/performance/client/RenderPerfTest/build.xml line 72:

> 70: 
> 71:     <!-- Put everything in ${build} into the J2DBench.jar file -->
> 72:     <jar jarfile="${dist}/RenderPerfTest.jar" basedir="${build}">

This was presumably borrowed from J2DBench so this comment should be fixed !

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

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

From prr at openjdk.java.net  Tue Mar  9 19:57:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 9 Mar 2021 19:57:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v8]
In-Reply-To: <g4FJx3rAG66rHxxlEzRf4q2pC_wVp7Qtw9jh5qsQ9JQ=.8f0637ea-e874-4b1b-b255-103527b2964c@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <alfbii4uc4NQLgHs1q26Yrjxx5bmtDWoEDjA2BUAfW8=.9264bf96-068b-4864-80e9-c83d16d5c53e@github.com>
 <leagyBpC8sFaseUwCyKmkNrgCXw1dgUhmyTBv_Z4U_Q=.116fddf2-5136-48ec-90a8-285db988d19d@github.com>
 <g4FJx3rAG66rHxxlEzRf4q2pC_wVp7Qtw9jh5qsQ9JQ=.8f0637ea-e874-4b1b-b255-103527b2964c@github.com>
Message-ID: <cB1FdvUx4Ca2Bw6fAnbURpHhpcJb4Bgv0eU4pfuD1m4=.2eb197fe-3aa1-4993-bcf8-48cdd74e8cc8@github.com>

On Mon, 15 Feb 2021 20:55:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Marked as reviewed by gziemski (Committer).
>
>> > > Thanks @gerard-ziemski for taking a detailed look at this.
>> > > We do have an open bug to address this. Please refer [JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825).
>> > 
>> > 
>> > Hi Gerard, expecting a process and parsing its output is definitely not ideal and that's why there's this open bug.
>> > One thing that is under consideration is to equate >= 10.14 with Metal is available since as of 10.14 macOS won't install if a system does not support metal. We have no compelling reason to support metal on earlier releases anyway .. those are either already unsupported or barely supported and OGL will always be available there.
>> 
>> I did not know that there already was a bug covering this issue.
>> 
>> Your idea seems reasonable.
>> 
>> More than just focusing on this immediate issue, however, I was hoping to raise the point of us starting adopting profiling tools to analyze our code (memory utilization, leaks, cpu/gpu profiling etc). A new feature that brings 10% benefit, but uses 50% more resources for example would probably not be a good investment. And to figure that we need to relay on some good tools and Xcode provides some.
> 
> There were actually tasks to do profiling of the memory footprint and look for leaks. We did not think it possible to be able to assert "Metal must use less memory than OpenGL" or dig into tiny differences but it was intended to find the big issues. See https://bugs.openjdk.java.net/browse/JDK-8237856
> @prsadhuk maybe able to say how much of it was doing using Xcode.

Regarding this  comment from @mrserb 
> Probably place it near J2Dbench?

I can't find the context but if it is suggesting moving RenderPerfTest to be co-located with J2Bench let's NOT do that.
It is much  more likely that J2DBench will be moved out of demo into test ...

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

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

From serb at openjdk.java.net  Tue Mar  9 20:21:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Mar 2021 20:21:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v11]
In-Reply-To: <3XzbfpM41bmyAd3DCXAqrSEJaFlA5-CCd9PUO5fKpD8=.88284596-8b8d-48eb-bf69-6ef5c3f55037@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <3XzbfpM41bmyAd3DCXAqrSEJaFlA5-CCd9PUO5fKpD8=.88284596-8b8d-48eb-bf69-6ef5c3f55037@github.com>
Message-ID: <oom8Y--xqXGRcU-gskMQQK2w767_ZOa2BsoTttP3X0g=.5c12bce2-a5d7-4ba1-a38a-9b5204f287b0@github.com>

On Mon, 8 Mar 2021 08:06:03 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 41 additional commits since the last revision:
> 
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#206 - 8262729 - aghaisas
>  - Lanai PR#205 - 8262496 - avu
>  - Lanai PR#203 - 8262313 - jdv
>  - Lanai PR#202 - 8262293 - avu
>  - Lanai PR#201 - 8261891 - avu
>  - ... and 31 more: https://git.openjdk.java.net/jdk/compare/851d3def...de456939

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 185:

> 183: 
> 184:     NSRect contentRect = NSMakeRect(0, 0, 64, 64);
> 185:     NSWindow *window =

Some remnant from the scratch surface initialization?

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

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

From serb at openjdk.java.net  Tue Mar  9 20:21:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Mar 2021 20:21:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
Message-ID: <vBPBNuySsnpPSev5ty-63rQqHEXLlarCR5wK3e7ABdo=.03e7f06a-3dff-438d-90e3-398a685ea66d@github.com>

On Sun, 7 Mar 2021 22:48:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 36 additional commits since the last revision:
>> 
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - Lanai PR#205 - 8262496 - avu
>>  - Lanai PR#203 - 8262313 - jdv
>>  - Lanai PR#202 - 8262293 - avu
>>  - Lanai PR#201 - 8261891 - avu
>>  - Lanai PR#200 - 8262115 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#199 - 8262091 - aghaisas
>>  - Lanai PR#198 - 8261646 - avu
>>  - Lanai PR#197 - 8261960 - jdv
>>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/af4701dd...5cb1fd91
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 676:
> 
>> 674:             height = srcInfo.bounds.y2 - srcInfo.bounds.y1;
>> 675: 
>> 676:             pDst = PtrAddBytes(pDst, dstx * dstInfo.pixelStride);
> 
> Here and in other places use the PtrPixelsRow instead, do not use multiplication, see the history of the OGLBlitLoops_SurfaceToSwBlit method.

I think this at least should be investigated before integration.

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

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

From aivanov at openjdk.java.net  Tue Mar  9 20:59:06 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 9 Mar 2021 20:59:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
Message-ID: <SpdZIFB7WtwGtTmUfWU8Z1yYkzYUadpRB_41rzqBm8s=.f69d7232-447e-447f-a8d3-09c949267c1d@github.com>

On Sat, 27 Feb 2021 18:33:52 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe

Marked as reviewed by aivanov (Reviewer).

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

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

From avu at openjdk.java.net  Tue Mar  9 22:21:31 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 9 Mar 2021 22:21:31 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
Message-ID: <m9PhvRjT1z3dhaG5BTyCCTYsM0AOISvjr-o6RyzLnkA=.03c4d554-b7fc-4a39-8978-d22dfc4c66a3@github.com>

On Mon, 1 Mar 2021 11:17:39 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 36 additional commits since the last revision:
> 
>  - Lanai PR#206 - 8262729 - aghaisas
>  - Lanai PR#205 - 8262496 - avu
>  - Lanai PR#203 - 8262313 - jdv
>  - Lanai PR#202 - 8262293 - avu
>  - Lanai PR#201 - 8261891 - avu
>  - Lanai PR#200 - 8262115 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#199 - 8262091 - aghaisas
>  - Lanai PR#198 - 8261646 - avu
>  - Lanai PR#197 - 8261960 - jdv
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/8f9013c3...5cb1fd91

Looks good, but a couple of things should be fixed (JDK-8263325, JDK-8263324)

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

Changes requested by avu (no project role).

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

From avu at openjdk.java.net  Tue Mar  9 22:21:32 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 9 Mar 2021 22:21:32 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <UQKFvwFicbVArPUl_E-mvmRhoRbIrE6BsyP9AN6MJkQ=.efa4917f-dff3-4ce8-8bcc-4e841e86020d@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
 <UQKFvwFicbVArPUl_E-mvmRhoRbIrE6BsyP9AN6MJkQ=.efa4917f-dff3-4ce8-8bcc-4e841e86020d@github.com>
Message-ID: <SQEdUuO8jhXIGdAvKrkdviEEAzzeCFbUpnNIJ_M-uxE=.9da8f91f-02b9-4486-a885-93b4d10ac5c5@github.com>

On Tue, 9 Mar 2021 17:26:24 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 68:
>> 
>>> 66:      * when disposing a texture-based surface).
>>> 67:      */
>>> 68:     public static void setScratchSurface(long pConfigInfo) {
>> 
>> How the scratch surface is used in the metal pipeline? Why it is not enough to set the "context current"?
>
> In fact, we don't have any scratch surfaces. SET_SCRATCH_SURFACE effectively sets the new context. For better readability, we should add the new op SET_CONTEXT in BufferedOpCodes

Probably it's enough to set the context in SET_SURFACES, I'll double-check it.

>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 140:
>> 
>>> 138:             StringBuilder sb = new StringBuilder(super.toString());
>>> 139:             if ((caps & CAPS_DOUBLEBUFFERED) != 0) {
>>> 140:                 sb.append("CAPS_DOUBLEBUFFERED|");
>> 
>> Related to other questions, we do not include CAPS_DOUBLEBUFFERED, but anyway, report the surface as double buffered.
>
> We can remove all the unused constants

JDK-8263306

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

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

From avu at openjdk.java.net  Tue Mar  9 22:21:44 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 9 Mar 2021 22:21:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
Message-ID: <vTEnRF92PmLsXlO-aHLfbQrs7Ao7mbhQ3y-zpDywaXg=.820a264c-c765-4bdb-a65a-9787eba1681f@github.com>

On Sun, 7 Mar 2021 22:31:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 36 additional commits since the last revision:
>> 
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - Lanai PR#205 - 8262496 - avu
>>  - Lanai PR#203 - 8262313 - jdv
>>  - Lanai PR#202 - 8262293 - avu
>>  - Lanai PR#201 - 8261891 - avu
>>  - Lanai PR#200 - 8262115 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#199 - 8262091 - aghaisas
>>  - Lanai PR#198 - 8261646 - avu
>>  - Lanai PR#197 - 8261960 - jdv
>>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/2f09d382...5cb1fd91
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLLayer.java line 44:
> 
>> 42: 
>> 43:     // Pass the insets to native code to make adjustments in blitTexture
>> 44:     private static native void nativeSetInsets(long layerPtr, int top, int left);
> 
> Probably I have asked this already, but why we need to use insets? Why insets is not necessary for ogl?

We have different coordinate systems for OGL and Metal. Metal (0,0) for textures is the top-left corner whereas OGL (0,0) is the bottom-left one, so we need to have insets to perform blitting to drawable correctly.

> src/java.desktop/macosx/classes/sun/java2d/metal/MTLBlitLoops.java line 499:
> 
>> 497:         }
>> 498: 
>> 499:         // We can convert argb_pre data from MTL surface in two places:
> 
> Does anybody check that this is true for the metal pipeline? or It is just copied from the OGL?

I fixed some conversion logic within JDK-8256331.

> src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 168:
> 
>> 166:         }
>> 167: 
>> 168:         ContextCapabilities caps = new MTLContext.MTLContextCaps(
> 
> CAPS_DOUBLEBUFFERED is not included?

JDK-8263306

> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 146:
> 
>> 144:                 return MTLSurfaceRTT;
>> 145:             default:
>> 146:                 return MTLSurface;
> 
> Do we really support 3 different types of surface? I guess only two of them are different: textures used for manageable images, and surfaces used by the volatile image.

It's true but I don't see any problem returning a more generic type as a default here

> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 221:
> 
>> 219:     protected native boolean initRTexture(long pData, boolean isOpaque, int width, int height);
>> 220: 
>> 221:     protected native boolean initFlipBackbuffer(long pData);
> 
> flip back buffer is supported?

No, it should be removed (JDK-8263312)

> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceData.m line 284:
> 
>> 282:  */
>> 283: jboolean
>> 284: MTLSD_InitMTLWindow(JNIEnv *env, BMTLSDOps *bmtlsdo)
> 
> When the MTLWindow is used?

MTLContext setSurfacesEnv

> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h line 109:
> 
>> 107: #define MTLSD_TEXTURE         sun_java2d_pipe_hw_AccelSurface_TEXTURE
>> 108: #define MTLSD_FLIP_BACKBUFFER sun_java2d_pipe_hw_AccelSurface_FLIP_BACKBUFFER
>> 109: #define MTLSD_RT_TEXTURE        sun_java2d_pipe_hw_AccelSurface_RT_TEXTURE
> 
> Only two of them are supported? MTLSD_TEXTURE and MTLSD_RT_TEXTURE?

Also, MTLSD_WINDOW is supported

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

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

From avu at openjdk.java.net  Tue Mar  9 22:21:44 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 9 Mar 2021 22:21:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <SQEdUuO8jhXIGdAvKrkdviEEAzzeCFbUpnNIJ_M-uxE=.9da8f91f-02b9-4486-a885-93b4d10ac5c5@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
 <UQKFvwFicbVArPUl_E-mvmRhoRbIrE6BsyP9AN6MJkQ=.efa4917f-dff3-4ce8-8bcc-4e841e86020d@github.com>
 <SQEdUuO8jhXIGdAvKrkdviEEAzzeCFbUpnNIJ_M-uxE=.9da8f91f-02b9-4486-a885-93b4d10ac5c5@github.com>
Message-ID: <xX3t6ybl0eT8hgR5ycqAlOxxM1sFHp_s18rim_SyQyY=.61e0d8df-aeda-4107-9ced-83b2d942fcc6@github.com>

On Tue, 9 Mar 2021 17:59:26 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> In fact, we don't have any scratch surfaces. SET_SCRATCH_SURFACE effectively sets the new context. For better readability, we should add the new op SET_CONTEXT in BufferedOpCodes
>
> Probably it's enough to set the context in SET_SURFACES, I'll double-check it.

Looks like it works even without SET_SCRATCH_SURFACE (I did some limited testing) but I don't think we should do such a huge change at this moment.

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

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

From avu at openjdk.java.net  Tue Mar  9 22:21:59 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 9 Mar 2021 22:21:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v11]
In-Reply-To: <hq4fQO_D6x4pPr2pI3EEM5Vh72eAkJV4zaORHcjESTc=.a49415b8-83c9-4e8d-a08f-afdeab6621fa@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <3XzbfpM41bmyAd3DCXAqrSEJaFlA5-CCd9PUO5fKpD8=.88284596-8b8d-48eb-bf69-6ef5c3f55037@github.com>
 <hq4fQO_D6x4pPr2pI3EEM5Vh72eAkJV4zaORHcjESTc=.a49415b8-83c9-4e8d-a08f-afdeab6621fa@github.com>
Message-ID: <wMsKwnbNFvM0VdlWXY-bSAGJDlqYhVGJm1iwH6-GiPE=.6adc5bbb-e77e-4de1-aa74-5bdcda421b7b@github.com>

On Tue, 9 Mar 2021 19:52:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> Ajit Ghaisas 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 41 additional commits since the last revision:
>> 
>>  - Lanai PR#210 - 8263159 - jdv
>>  - Lanai PR#209 - 8262936 - jdv
>>  - Lanai PR#208 - 8262928 - jdv
>>  - Lanai PR#207 - 8262750 - jdv
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - Lanai PR#205 - 8262496 - avu
>>  - Lanai PR#203 - 8262313 - jdv
>>  - Lanai PR#202 - 8262293 - avu
>>  - Lanai PR#201 - 8261891 - avu
>>  - ... and 31 more: https://git.openjdk.java.net/jdk/compare/1bd8aea0...de456939
>
> test/jdk/performance/client/RenderPerfTest/build.xml line 72:
> 
>> 70: 
>> 71:     <!-- Put everything in ${build} into the J2DBench.jar file -->
>> 72:     <jar jarfile="${dist}/RenderPerfTest.jar" basedir="${build}">
> 
> This was presumably borrowed from J2DBench so this comment should be fixed !

JDK-8263325

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

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

From avu at openjdk.java.net  Tue Mar  9 22:21:45 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 9 Mar 2021 22:21:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <vBPBNuySsnpPSev5ty-63rQqHEXLlarCR5wK3e7ABdo=.03e7f06a-3dff-438d-90e3-398a685ea66d@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
 <vBPBNuySsnpPSev5ty-63rQqHEXLlarCR5wK3e7ABdo=.03e7f06a-3dff-438d-90e3-398a685ea66d@github.com>
Message-ID: <cHOmircrQXZn1-ep0myn_G1epBy8sltqJw9FU-yMKTg=.bcdc9e7c-547d-455c-8c07-47c70a5bca4c@github.com>

On Tue, 9 Mar 2021 20:13:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 676:
>> 
>>> 674:             height = srcInfo.bounds.y2 - srcInfo.bounds.y1;
>>> 675: 
>>> 676:             pDst = PtrAddBytes(pDst, dstx * dstInfo.pixelStride);
>> 
>> Here and in other places use the PtrPixelsRow instead, do not use multiplication, see the history of the OGLBlitLoops_SurfaceToSwBlit method.
>
> I think this at least should be investigated before integration.

JDK-8263324

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

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

From avu at openjdk.java.net  Tue Mar  9 22:21:44 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 9 Mar 2021 22:21:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <xX3t6ybl0eT8hgR5ycqAlOxxM1sFHp_s18rim_SyQyY=.61e0d8df-aeda-4107-9ced-83b2d942fcc6@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
 <UQKFvwFicbVArPUl_E-mvmRhoRbIrE6BsyP9AN6MJkQ=.efa4917f-dff3-4ce8-8bcc-4e841e86020d@github.com>
 <SQEdUuO8jhXIGdAvKrkdviEEAzzeCFbUpnNIJ_M-uxE=.9da8f91f-02b9-4486-a885-93b4d10ac5c5@github.com>
 <xX3t6ybl0eT8hgR5ycqAlOxxM1sFHp_s18rim_SyQyY=.61e0d8df-aeda-4107-9ced-83b2d942fcc6@github.com>
Message-ID: <nSXPYFmCQpNK-9BmUrJIuzchV5bDWj_ZuVer6zw5C8k=.de4f00cb-bf6a-4522-880b-7c5512b1c174@github.com>

On Tue, 9 Mar 2021 20:04:17 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Probably it's enough to set the context in SET_SURFACES, I'll double-check it.
>
> Looks like it works even without SET_SCRATCH_SURFACE (I did some limited testing) but I don't think we should do such a huge change at this moment.

JDK-8263309

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

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

From serb at openjdk.java.net  Tue Mar  9 22:31:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Mar 2021 22:31:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <SpdZIFB7WtwGtTmUfWU8Z1yYkzYUadpRB_41rzqBm8s=.f69d7232-447e-447f-a8d3-09c949267c1d@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
 <SpdZIFB7WtwGtTmUfWU8Z1yYkzYUadpRB_41rzqBm8s=.f69d7232-447e-447f-a8d3-09c949267c1d@github.com>
Message-ID: <OcWjYU695W8N1MktyAT-KeKEQm_aVlxAe24psIrPVFc=.4bf45820-038e-471b-ac4a-f343403b39a3@github.com>

On Tue, 9 Mar 2021 20:56:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe
>
> Marked as reviewed by aivanov (Reviewer).

> I don't know why making this volatile is doing anything.
> Let's discuss this further.

It will prevent the possibility that one thread will store the non-null value to the SunFontManager.platformFontMap and only after that complete initialization of object stored in that field due to code optimizations. It is similar to the volatile DCL:
see "broken multithreaded version" example:
https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java

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

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

From serb at openjdk.java.net  Tue Mar  9 23:19:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Mar 2021 23:19:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <vTEnRF92PmLsXlO-aHLfbQrs7Ao7mbhQ3y-zpDywaXg=.820a264c-c765-4bdb-a65a-9787eba1681f@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
 <vTEnRF92PmLsXlO-aHLfbQrs7Ao7mbhQ3y-zpDywaXg=.820a264c-c765-4bdb-a65a-9787eba1681f@github.com>
Message-ID: <PZSsyAQ4ras6jBm4u-FrY8hlo5llqxPgxP_VauEmm3Y=.9862cc2c-904f-4915-9337-721767493f20@github.com>

On Tue, 9 Mar 2021 22:11:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h line 109:
>> 
>>> 107: #define MTLSD_TEXTURE         sun_java2d_pipe_hw_AccelSurface_TEXTURE
>>> 108: #define MTLSD_FLIP_BACKBUFFER sun_java2d_pipe_hw_AccelSurface_FLIP_BACKBUFFER
>>> 109: #define MTLSD_RT_TEXTURE        sun_java2d_pipe_hw_AccelSurface_RT_TEXTURE
>> 
>> Only two of them are supported? MTLSD_TEXTURE and MTLSD_RT_TEXTURE?
>
> Also, MTLSD_WINDOW is supported

How it is used? Can we really draw to the window directly? It looks like it copied from the OGL where it is unused since CLayer integration. Something is inconsistent here.

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

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

From serb at openjdk.java.net  Wed Mar 10 00:58:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Mar 2021 00:58:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons
In-Reply-To: <Xj2xcoi5vCQg0gxZizxxEvomvz32LRd6DbBdwqOa1yA=.f677bea5-7cb5-4ce8-85e8-e53c63162bf2@github.com>
References: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
 <Xj2xcoi5vCQg0gxZizxxEvomvz32LRd6DbBdwqOa1yA=.f677bea5-7cb5-4ce8-85e8-e53c63162bf2@github.com>
Message-ID: <k14k-HWeBnOeJgnLPhjGYzBT4vg2lUeXebzd7c95ydo=.acc86f18-fab8-4d9d-bb45-22e72dea7fd9@github.com>

On Mon, 8 Mar 2021 13:23:00 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Fix updated after first round of review.
>
> Continuation of review at https://github.com/openjdk/jdk/pull/380

Just to continue the thread from the old review, did you have a chance to look at the possibility of loading all existed icons embedded in the file? It was discussed here:
https://github.com/openjdk/jdk/pull/380#issuecomment-702999573

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

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

From serb at openjdk.java.net  Wed Mar 10 01:51:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Mar 2021 01:51:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with
 low DPI has bad quality on Windows
In-Reply-To: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
References: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
Message-ID: <qKNIwmgzMj_MlyRCSm9y4DNdSEx2Z9EXdtkVh3Rx7Io=.218fc80b-680f-4911-a220-e1f8e24ee6be@github.com>

On Fri, 26 Feb 2021 19:40:22 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
> 
> The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page".
> 
> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
> 
> The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
> 
> I tried to put wPrinterJob.beginPath()/endPath()  methods around wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape.
> 
> The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method.
> The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() .
> 
> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix.
> 
> There are two failed automated tests which fail without the fix as well:
> java/awt/print/PrinterJob/GlyphPositions.java 
> java/awt/print/PrinterJob/PSQuestionMark.java
> 
> The following manual tests have issues on my system:
> - `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static"
> 
> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons.
> 
> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
> 
> 
> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain  print/pass/fail buttons and it is not possible to close the window.
> 
> - The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message:
> java/awt/print/Dialog/DialogOrient.java
> java/awt/print/Dialog/DialogType.java
> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
> java/awt/print/PrinterJob/PageDialogTest.java
> java/awt/print/PrinterJob/PageRanges.java
> java/awt/print/PrinterJob/PageRangesDlgTest.java
> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
> java/awt/print/PrinterJob/PrintLatinCJKTest.java
> java/awt/print/PrinterJob/PrintTextTest.java
> java/awt/print/PrinterJob/SwingUIText.java
> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
> java/awt/PrintJob/SaveDialogTitleTest.java

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Wed Mar 10 01:51:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Mar 2021 01:51:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with
 low DPI has bad quality on Windows
In-Reply-To: <qKNIwmgzMj_MlyRCSm9y4DNdSEx2Z9EXdtkVh3Rx7Io=.218fc80b-680f-4911-a220-e1f8e24ee6be@github.com>
References: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
 <qKNIwmgzMj_MlyRCSm9y4DNdSEx2Z9EXdtkVh3Rx7Io=.218fc80b-680f-4911-a220-e1f8e24ee6be@github.com>
Message-ID: <_gyOC67AaHPv8HdVXHlnYRxJI5tE7C48m7O92zGhmLA=.7d446a78-55c5-4d4a-9646-19a9c2ee7c71@github.com>

On Wed, 10 Mar 2021 01:48:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
>> The GDI system used for text printing on Windows accepts only integer path coordinates.
>> Rounding GlyphVector outline coordinates leads to distorted printed text.
>> 
>> The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page".
>> 
>> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
>> 
>> The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
>> 
>> I tried to put wPrinterJob.beginPath()/endPath()  methods around wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape.
>> 
>> The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method.
>> The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() .
>> 
>> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix.
>> 
>> There are two failed automated tests which fail without the fix as well:
>> java/awt/print/PrinterJob/GlyphPositions.java 
>> java/awt/print/PrinterJob/PSQuestionMark.java
>> 
>> The following manual tests have issues on my system:
>> - `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static"
>> 
>> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons.
>> 
>> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
>> 
>> 
>> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain  print/pass/fail buttons and it is not possible to close the window.
>> 
>> - The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message:
>> java/awt/print/Dialog/DialogOrient.java
>> java/awt/print/Dialog/DialogType.java
>> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
>> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
>> java/awt/print/PrinterJob/PageDialogTest.java
>> java/awt/print/PrinterJob/PageRanges.java
>> java/awt/print/PrinterJob/PageRangesDlgTest.java
>> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
>> java/awt/print/PrinterJob/PrintLatinCJKTest.java
>> java/awt/print/PrinterJob/PrintTextTest.java
>> java/awt/print/PrinterJob/SwingUIText.java
>> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
>> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
>> java/awt/PrintJob/SaveDialogTitleTest.java
>
> Marked as reviewed by serb (Reviewer).

@prsadhuk please take a look

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

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

From kizune at openjdk.java.net  Wed Mar 10 05:39:06 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 10 Mar 2021 05:39:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons
In-Reply-To: <k14k-HWeBnOeJgnLPhjGYzBT4vg2lUeXebzd7c95ydo=.acc86f18-fab8-4d9d-bb45-22e72dea7fd9@github.com>
References: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
 <Xj2xcoi5vCQg0gxZizxxEvomvz32LRd6DbBdwqOa1yA=.f677bea5-7cb5-4ce8-85e8-e53c63162bf2@github.com>
 <k14k-HWeBnOeJgnLPhjGYzBT4vg2lUeXebzd7c95ydo=.acc86f18-fab8-4d9d-bb45-22e72dea7fd9@github.com>
Message-ID: <nDqbq827JWyJKW1wODZOgFD7V5_lhNXnqM0Ed-RS9MI=.02fe6931-6c30-4ad9-a577-20768bcf1b69@github.com>

On Wed, 10 Mar 2021 00:55:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Continuation of review at https://github.com/openjdk/jdk/pull/380
>
> Just to continue the thread from the old review, did you have a chance to look at the possibility of loading all existed icons embedded in the file? It was discussed here:
> https://github.com/openjdk/jdk/pull/380#issuecomment-702999573

> Just to continue the thread from the old review, did you have a chance to look at the possibility of loading all existed icons embedded in the file? It was discussed here:
> [#380 (comment)](https://github.com/openjdk/jdk/pull/380#issuecomment-702999573)

Yes, i did. There were 3 shortcomings: 1. It works in about 10% of the cases in all other cases it reports only one icon available (32x32) even if there are other resolution icons. 2. It is quite  slow, especially on network drives. 3. Does not work at all in files that are within AppData\Roaming folder - returning list is just empty.

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

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

From kizune at openjdk.java.net  Wed Mar 10 09:32:09 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 10 Mar 2021 09:32:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
Message-ID: <sDpfURNphkrxsd5fgaeMFS9nNfxdmYf78X4y0-e4H1k=.b294880a-7437-4bad-be01-558f09be2083@github.com>

On Sat, 27 Feb 2021 18:33:52 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe

Marked as reviewed by kizune (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 09:42:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 09:42:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with
 low DPI has bad quality on Windows
In-Reply-To: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
References: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
Message-ID: <z-ZS7TWcjnioODkkg2P4xCrXeFCvueuwbBKf6dsNT0E=.f7c9006e-5712-4d7c-9038-9c195affcae6@github.com>

On Fri, 26 Feb 2021 19:40:22 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
> 
> The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page".
> 
> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
> 
> The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
> 
> I tried to put wPrinterJob.beginPath()/endPath()  methods around wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape.
> 
> The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method.
> The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() .
> 
> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix.
> 
> There are two failed automated tests which fail without the fix as well:
> java/awt/print/PrinterJob/GlyphPositions.java 
> java/awt/print/PrinterJob/PSQuestionMark.java
> 
> The following manual tests have issues on my system:
> - `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static"
> 
> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons.
> 
> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
> 
> 
> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain  print/pass/fail buttons and it is not possible to close the window.
> 
> - The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message:
> java/awt/print/Dialog/DialogOrient.java
> java/awt/print/Dialog/DialogType.java
> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
> java/awt/print/PrinterJob/PageDialogTest.java
> java/awt/print/PrinterJob/PageRanges.java
> java/awt/print/PrinterJob/PageRangesDlgTest.java
> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
> java/awt/print/PrinterJob/PrintLatinCJKTest.java
> java/awt/print/PrinterJob/PrintTextTest.java
> java/awt/print/PrinterJob/SwingUIText.java
> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
> java/awt/PrintJob/SaveDialogTitleTest.java

src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1025:

> 1023:      * {@code GM_COMPATIBLE} or {@code GM_ADVANCED}.
> 1024:      */
> 1025:     private int setGraphicsMode(int mode) {

Is there any need of "int" return value? I dont see it is used in restoreTransform()

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 09:46:08 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 09:46:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with
 low DPI has bad quality on Windows
In-Reply-To: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
References: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
Message-ID: <ae7fxpsyfo6w1xn203qZmLKFjT2l5CTX8BY2iayflBs=.2a7603b4-2691-49be-b10c-a154fca28d15@github.com>

On Fri, 26 Feb 2021 19:40:22 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
> 
> The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page".
> 
> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
> 
> The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
> 
> I tried to put wPrinterJob.beginPath()/endPath()  methods around wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape.
> 
> The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method.
> The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() .
> 
> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix.
> 
> There are two failed automated tests which fail without the fix as well:
> java/awt/print/PrinterJob/GlyphPositions.java 
> java/awt/print/PrinterJob/PSQuestionMark.java
> 
> The following manual tests have issues on my system:
> - `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static"
> 
> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons.
> 
> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
> 
> 
> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain  print/pass/fail buttons and it is not possible to close the window.
> 
> - The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message:
> java/awt/print/Dialog/DialogOrient.java
> java/awt/print/Dialog/DialogType.java
> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
> java/awt/print/PrinterJob/PageDialogTest.java
> java/awt/print/PrinterJob/PageRanges.java
> java/awt/print/PrinterJob/PageRangesDlgTest.java
> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
> java/awt/print/PrinterJob/PrintLatinCJKTest.java
> java/awt/print/PrinterJob/PrintTextTest.java
> java/awt/print/PrinterJob/SwingUIText.java
> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
> java/awt/PrintJob/SaveDialogTitleTest.java

src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 2033:

> 2031:     xForm.eDy  = (FLOAT) elems[5];
> 2032: 
> 2033:     ::SetWorldTransform((HDC)printDC, &xForm);

Probably we should check for the return value of all this system APIs SetGraphicsMode, GetWorldTransform, SetWorldTransform, ModifyWorldTransform to see if it succeeded?

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

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

From aghaisas at openjdk.java.net  Wed Mar 10 10:51:08 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 10 Mar 2021 10:51:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v12]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <OwqKVRF3i72HyNbRK4ljD--kQX0Jdszyfe3CbeDRsrI=.494c5b84-dc8d-4e1c-b647-48fd8ae5b03e@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

Ajit Ghaisas 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 45 additional commits since the last revision:

 - Lanai PR#213 - 8263325 - avu
 - Lanai PR#212 - 8259825 - aghaisas
 - Lanai PR#211 - 8262882 - aghaisas
 - Merge branch 'master' into 8260931_lanai_JEP_branch
 - Lanai PR#210 - 8263159 - jdv
 - Lanai PR#209 - 8262936 - jdv
 - Lanai PR#208 - 8262928 - jdv
 - Lanai PR#207 - 8262750 - jdv
 - Merge branch 'master' into 8260931_lanai_JEP_branch
 - Lanai PR#206 - 8262729 - aghaisas
 - ... and 35 more: https://git.openjdk.java.net/jdk/compare/dfe037de...3980ecbd

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/de456939..3980ecbd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=10-11

  Stats: 4881 lines in 177 files changed: 1767 ins; 2327 del; 787 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

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

From aghaisas at openjdk.java.net  Wed Mar 10 11:58:20 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 10 Mar 2021 11:58:20 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
Message-ID: <JbULJPOJ13dlGD0pH_H6B_0LnCGLah9ll8QSPzs4BAs=.f3eee656-1574-4bd4-9321-7ad29dd08739@github.com>

On Sun, 7 Mar 2021 22:40:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 36 additional commits since the last revision:
>> 
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - Lanai PR#205 - 8262496 - avu
>>  - Lanai PR#203 - 8262313 - jdv
>>  - Lanai PR#202 - 8262293 - avu
>>  - Lanai PR#201 - 8261891 - avu
>>  - Lanai PR#200 - 8262115 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#199 - 8262091 - aghaisas
>>  - Lanai PR#198 - 8261646 - avu
>>  - Lanai PR#197 - 8261960 - jdv
>>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/33534417...5cb1fd91
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CWarningWindow.java line 304:
> 
>> 302:                 };
>> 303:             }
>> 304:             public MTLLayer createMTLLayer() {
> 
> TODO to test that this functionality works

Testing was done under JDK-8261141.

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

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

From aghaisas at openjdk.java.net  Wed Mar 10 11:58:32 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 10 Mar 2021 11:58:32 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v11]
In-Reply-To: <oom8Y--xqXGRcU-gskMQQK2w767_ZOa2BsoTttP3X0g=.5c12bce2-a5d7-4ba1-a38a-9b5204f287b0@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <3XzbfpM41bmyAd3DCXAqrSEJaFlA5-CCd9PUO5fKpD8=.88284596-8b8d-48eb-bf69-6ef5c3f55037@github.com>
 <oom8Y--xqXGRcU-gskMQQK2w767_ZOa2BsoTttP3X0g=.5c12bce2-a5d7-4ba1-a38a-9b5204f287b0@github.com>
Message-ID: <HTOXm4HjYNW4MrcwAeuQMeJnj3Vx65MSbvI9O5VXUog=.92851a08-2249-4c52-9203-83206d50e12f@github.com>

On Tue, 9 Mar 2021 20:18:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 41 additional commits since the last revision:
>> 
>>  - Lanai PR#210 - 8263159 - jdv
>>  - Lanai PR#209 - 8262936 - jdv
>>  - Lanai PR#208 - 8262928 - jdv
>>  - Lanai PR#207 - 8262750 - jdv
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - Lanai PR#205 - 8262496 - avu
>>  - Lanai PR#203 - 8262313 - jdv
>>  - Lanai PR#202 - 8262293 - avu
>>  - Lanai PR#201 - 8261891 - avu
>>  - ... and 31 more: https://git.openjdk.java.net/jdk/compare/d65116dd...de456939
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 185:
> 
>> 183: 
>> 184:     NSRect contentRect = NSMakeRect(0, 0, 64, 64);
>> 185:     NSWindow *window =
> 
> Some remnant from the scratch surface initialization?

This will be removed under - JDK-8263363

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

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

From bourges.laurent at gmail.com  Wed Mar 10 12:19:16 2021
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 10 Mar 2021 13:19:16 +0100
Subject: [OpenJDK 2D-Dev] Rendering images from PDF files slower in
 OpenJDK
In-Reply-To: <6b7208d7-a528-882e-8f5a-920539c2b8ae@oracle.com>
References: <CALLYd6TyN2Fc+vFOrg9e-RA+M67G56gJ8E1jn+1CnFYkz6cKZg@mail.gmail.com>
 <873cc9de-604f-8b11-a5ba-fcccf4337e81@oracle.com>
 <CAKjRUT5XqGdVO10UDJK7VuS5nEo_p0pDohxm=GiMqosdzA7Tgw@mail.gmail.com>
 <a281fd1e-2702-1de3-b4df-823fb3f6c2b2@oracle.com>
 <CAKjRUT5U1=EqYNpM64Wr-GmX2WKnjC5VThOcnSNEgvQi2zg1ew@mail.gmail.com>
 <CALLYd6RPjJBss_eTnfAA6UomY=Eis0iu+Lj8Zp_7sO1LEKkQeA@mail.gmail.com>
 <CAKjRUT4BKY-5L=WVtcgNkTGHFERmdop5r9xZBe_aF8yQef2Stg@mail.gmail.com>
 <fbb24f35-44be-17e4-1b33-01b72faa328d@oracle.com>
 <CAKjRUT4x4vxHLH+XHfc5Lh7u5FQ0eexauGPcwS8p3tLdymC9wA@mail.gmail.com>
 <5BB68521.7040708@oracle.com> <5BB69B8A.3040106@oracle.com>
 <CAKjRUT68rT=RaMqCau3O1d86eFDkgg1KZLMXhyXowubXcdt9uw@mail.gmail.com>
 <CALLYd6TgJxnisWrtKWFAn58nGe6_DD4vdM-iByeGwNTqSL6dnA@mail.gmail.com>
 <5BB6F64F.2080303@oracle.com>
 <CALLYd6TigE9vg9N8EkwfosyDOgwh3va++ZVmOJ5w67PrfJMMzQ@mail.gmail.com>
 <5BB6FF4A.3090105@oracle.com>
 <CAKjRUT7ALdjKA5ZvdO8LV3_cGAOTBRtjZu7xQ9zcccPfPdBb8w@mail.gmail.com>
 <6b7208d7-a528-882e-8f5a-920539c2b8ae@oracle.com>
Message-ID: <CAKjRUT440vtC4nMWCj0wGqmrCLv4vwKux-SCGAWvdOEVo0+U-Q@mail.gmail.com>

Hi Sergey,

Le lun. 8 mars 2021 ? 06:00, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> a
?crit :

> Hi, Laurent.
>
> On 04.10.2018 23:45, Laurent Bourg?s wrote:
> > I looks like a call to let me have a look. Maybe I could inspect what
> makes LCMS slow (lerp?) ... and optimize the C code or at least tune gcc
> options.
>
> Did you have a chance to look at it? =)
>

No, I agreed with phil, it is more a LCMS optimization task, for anybody
involved in this project.

I could have a look since, but no time nor motivation, sorry.

This ticket is closeable or stalled until someone rewrites LCMS to be more
efficient.

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210310/3e26dd27/attachment.htm>

From mbaesken at openjdk.java.net  Wed Mar 10 12:36:18 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 10 Mar 2021 12:36:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in
 java/awt/font/TextJustifier.java justify
Message-ID: <fY0ZM20o_3k5AyBaahIMnsWvKN-S2EHO4FR1hRkvzQM=.f745ba0c-19f0-4129-b3da-5c6748973ccc@github.com>

In java/awt/font/TextJustifier.java justify-method there is a potential code path where divison by zero might happen , see also the Sonar finding 
https://sonarcloud.io/project/issues?id=shipilev_jdk&open=AXcqMwpm8sPJZZzONu1k&resolved=false&severities=CRITICAL&types=BUG


            boolean hitLimit = (weight == 0) || (!lastPass && ((delta < 0) == (delta < gslimit)));
            boolean absorbing = hitLimit && absorbweight > 0;
            // predivide delta by weight
            float weightedDelta = delta / weight; // not used if weight == 0

In case of (weight == 0) the division should not be done because the value of weightedDelta is unused in this case anyway.

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

Commit messages:
 - JDK-8263362

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

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

From psadhukhan at openjdk.java.net  Wed Mar 10 12:44:10 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Mar 2021 12:44:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in
 java/awt/font/TextJustifier.java justify
In-Reply-To: <fY0ZM20o_3k5AyBaahIMnsWvKN-S2EHO4FR1hRkvzQM=.f745ba0c-19f0-4129-b3da-5c6748973ccc@github.com>
References: <fY0ZM20o_3k5AyBaahIMnsWvKN-S2EHO4FR1hRkvzQM=.f745ba0c-19f0-4129-b3da-5c6748973ccc@github.com>
Message-ID: <VLkXFIeLylWzWQI-oDdbsBygj4wyJRFzVR_bupAkNoY=.c509f2c2-f9d9-42aa-b476-16447f2bf4ee@github.com>

On Wed, 10 Mar 2021 12:31:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In java/awt/font/TextJustifier.java justify-method there is a potential code path where divison by zero might happen , see also the Sonar finding 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&open=AXcqMwpm8sPJZZzONu1k&resolved=false&severities=CRITICAL&types=BUG
> 
> 
>             boolean hitLimit = (weight == 0) || (!lastPass && ((delta < 0) == (delta < gslimit)));
>             boolean absorbing = hitLimit && absorbweight > 0;
>             // predivide delta by weight
>             float weightedDelta = delta / weight; // not used if weight == 0
> 
> In case of (weight == 0) the division should not be done because the value of weightedDelta is unused in this case anyway.

src/java.desktop/share/classes/java/awt/font/TextJustifier.java line 159:

> 157:             // predivide delta by weight
> 158:             float weightedDelta = 0;
> 159:             if (weight != 0) { // not used if weight == 0

Can it ever be -ve? Maybe we can do weight > 0 check just as we do for absorbweight?

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

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

From mbaesken at openjdk.java.net  Wed Mar 10 12:58:08 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 10 Mar 2021 12:58:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in
 java/awt/font/TextJustifier.java justify
In-Reply-To: <VLkXFIeLylWzWQI-oDdbsBygj4wyJRFzVR_bupAkNoY=.c509f2c2-f9d9-42aa-b476-16447f2bf4ee@github.com>
References: <fY0ZM20o_3k5AyBaahIMnsWvKN-S2EHO4FR1hRkvzQM=.f745ba0c-19f0-4129-b3da-5c6748973ccc@github.com>
 <VLkXFIeLylWzWQI-oDdbsBygj4wyJRFzVR_bupAkNoY=.c509f2c2-f9d9-42aa-b476-16447f2bf4ee@github.com>
Message-ID: <x8I0ycHMlatXczQ7XcmGUCHAvDLTmHiR4OvD26qBGs4=.edb854a1-789c-4a20-8c37-d5d6dc916f7b@github.com>

On Wed, 10 Mar 2021 12:41:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In java/awt/font/TextJustifier.java justify-method there is a potential code path where divison by zero might happen , see also the Sonar finding 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&open=AXcqMwpm8sPJZZzONu1k&resolved=false&severities=CRITICAL&types=BUG
>> 
>> 
>>             boolean hitLimit = (weight == 0) || (!lastPass && ((delta < 0) == (delta < gslimit)));
>>             boolean absorbing = hitLimit && absorbweight > 0;
>>             // predivide delta by weight
>>             float weightedDelta = delta / weight; // not used if weight == 0
>> 
>> In case of (weight == 0) the division should not be done because the value of weightedDelta is unused in this case anyway.
>
> src/java.desktop/share/classes/java/awt/font/TextJustifier.java line 159:
> 
>> 157:             // predivide delta by weight
>> 158:             float weightedDelta = 0;
>> 159:             if (weight != 0) { // not used if weight == 0
> 
> Can it ever be -ve? Maybe we can do weight > 0 check just as we do for absorbweight?

Hi, I am not sure about the  weight > 0  check ; weight is initialized with 0:   weight = 0;   and later some values are potentially added up to weight:   weight += gi.weight;
I am not sure about those gi.weight values, maybe they can be negative too ?

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

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

From kcr at openjdk.java.net  Wed Mar 10 14:16:34 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 10 Mar 2021 14:16:34 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v12]
In-Reply-To: <OwqKVRF3i72HyNbRK4ljD--kQX0Jdszyfe3CbeDRsrI=.494c5b84-dc8d-4e1c-b647-48fd8ae5b03e@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <OwqKVRF3i72HyNbRK4ljD--kQX0Jdszyfe3CbeDRsrI=.494c5b84-dc8d-4e1c-b647-48fd8ae5b03e@github.com>
Message-ID: <8X7UHwOUe93kdQadaAFIyuLU5Q0Z6lOKJLwaceNMgGg=.de725ee4-d235-4618-9b02-c82ac51855df@github.com>

On Wed, 10 Mar 2021 10:51:08 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 45 additional commits since the last revision:
> 
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#206 - 8262729 - aghaisas
>  - ... and 35 more: https://git.openjdk.java.net/jdk/compare/42b2f14b...3980ecbd

Marked as reviewed by kcr (Author).

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

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

From aivanov at openjdk.java.net  Wed Mar 10 15:43:24 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Mar 2021 15:43:24 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for remote
 printers update instead of polling
Message-ID: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>

[JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented polling for remote printers.
That bug description also mentions watching the registry for changes and links to the article which describes the method yet it does so in terms of WMI. Using WMI is not necessary to watch for the registry updates.

It is possible to replace polling mechanism with registry change notifications. If the registry at `HKCU\Printers\Connections` is updated, refresh the list of print services.

It works perfectly well in my own testing with sharing a Generic / Text Only printer from another laptop. The notification comes as soon as the printer is installed, it results in a new key created under `Connections`. If a remote printer is removed, the notification is also triggered as the key corresponding to that printer is removed from the registry.

I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`.

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

Commit messages:
 - 8263311: Watch registry changes for remote printers update instead of polling

Changes: https://git.openjdk.java.net/jdk/pull/2915/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2915&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263311
  Stats: 207 lines in 3 files changed: 31 ins; 158 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2915/head:pull/2915

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

From prr at openjdk.java.net  Wed Mar 10 18:52:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 10 Mar 2021 18:52:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in
 java/awt/font/TextJustifier.java justify
In-Reply-To: <x8I0ycHMlatXczQ7XcmGUCHAvDLTmHiR4OvD26qBGs4=.edb854a1-789c-4a20-8c37-d5d6dc916f7b@github.com>
References: <fY0ZM20o_3k5AyBaahIMnsWvKN-S2EHO4FR1hRkvzQM=.f745ba0c-19f0-4129-b3da-5c6748973ccc@github.com>
 <VLkXFIeLylWzWQI-oDdbsBygj4wyJRFzVR_bupAkNoY=.c509f2c2-f9d9-42aa-b476-16447f2bf4ee@github.com>
 <x8I0ycHMlatXczQ7XcmGUCHAvDLTmHiR4OvD26qBGs4=.edb854a1-789c-4a20-8c37-d5d6dc916f7b@github.com>
Message-ID: <dNsNq4A92M76X9DxGoNy2MRtEWmySjzTqXGEW4nNf0Y=.a2cef167-6287-42d9-8313-248c7d25d8d9@github.com>

On Wed, 10 Mar 2021 12:55:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/font/TextJustifier.java line 159:
>> 
>>> 157:             // predivide delta by weight
>>> 158:             float weightedDelta = 0;
>>> 159:             if (weight != 0) { // not used if weight == 0
>> 
>> Can it ever be -ve? Maybe we can do weight > 0 check just as we do for absorbweight?
>
> Hi, I am not sure about the  weight > 0  check ; weight is initialized with 0:   weight = 0;   and later some values are potentially added up to weight:   weight += gi.weight;
> I am not sure about those gi.weight values, maybe they can be negative too ?

Nothing throws an exception or otherwise prevent this being negative but that would be a weird usage. Typically the weight is either zero or based on the font size .. which ought not to be negative but I don't think anything prevents it and I think we would treat it essentially as a transform. So If you really want to be careful here, then yes assume weight could be negative.

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

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

From aivanov at openjdk.java.net  Wed Mar 10 21:01:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 10 Mar 2021 21:01:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons
In-Reply-To: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
References: <e1blsXETihJeuQUW6-ERVupKC2uGEq56ZCnX0x3h-vA=.007de252-fc87-4e4c-9c6d-180e90f38e9a@github.com>
Message-ID: <t5ysQOmFRTcCh3mbaeMa0YICTaquTspXV-9XyZd2rfc=.0dd1be0c-1e4c-412a-9530-601ee70cbebf@github.com>

On Mon, 8 Mar 2021 13:22:07 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Fix updated after first round of review.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1044:

> 1042:                         new BufferedImage(iconSize, iconSize, BufferedImage.TYPE_INT_ARGB);
> 1043:                 img.setRGB(0, 0, iconSize, iconSize, iconBits, 0, iconSize);
> 1044:                 return img;

There are cases where the size of the buffered image is different from the requested size. It could affect the layout because it breaks the assumption that the returned image has the requested size but it may be larger. (Or is it no longer possible?) I think it should be wrapped into `MultiResolutionIconImage` in this case.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1114:

> 1112:                                     bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);
> 1113:                                     newIcon = new MultiResolutionIconImage(getLargeIcon ? LARGE_ICON_SIZE
> 1114:                                             : SMALL_ICON_SIZE, bothIcons);

I still propose to refactor this code to make it clearer. The code always returns two icons: _small + large_ or _large + small_ ? combined in `MultiResolutionIconImage`.

You can get `smallIcon` and `largeIcon` and then wrap them into `MultiResolutionIconImage` in the correct order and store each icon in the cache.

My opinion hasn't changed here.

I still think there's not much value in getting smaller icon size in addition to larger one. Or does it provide an alternative image for the case where the system scaling is 200% and the window is moved to a monitor with scaling of 100%?

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1195:

> 1193:      */
> 1194:     static Image getShell32Icon(int iconID, int size) {
> 1195:         boolean useVGAColors = true; // Will be ignored on XP and later

I cannot see where `useVGAColors` is used. Since the supported OS are later than XP, it can be removed, can't it?

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 983:

> 981:                 size = 16;
> 982:             }
> 983:             hres = pIcon->Extract(szBuf, index, &hIcon, NULL, (16 << 16) + size);

Suggestion:

            hres = pIcon->Extract(szBuf, index, &hIcon, NULL, size);
Now you request only one icon.

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 64:

> 62:             }
> 63: 
> 64:             if (icon.getIconWidth() != size) {

Does it make sense to check that the icon is a multi-resolution image with the expected sizes?
We know for sure `explorer.exe` contains the entire set of icons.

src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 264:

> 262:     * <p>
> 263:     * The default implementation gets information from the
> 264:     * <code>ShellFolder</code> class. Whenever possible, the icon

Do we continue using `<code>` elements? I thought that {@code} is the preferred way to markup class names.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1112:

> 1110:                                     Map<Integer, Image> bothIcons = new HashMap<>(2);
> 1111:                                     bothIcons.put(getLargeIcon? LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);
> 1112:                                     bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);

Suggestion:

                                    bothIcons.put(getLargeIcon ? LARGE_ICON_SIZE : SMALL_ICON_SIZE, newIcon);
                                    bothIcons.put(getLargeIcon ? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1146:

> 1144:             }
> 1145:             Map<Integer, Image> multiResolutionIcon = new HashMap<>();
> 1146:             int start = size > MAX_QUALITY_ICON ? ICON_RESOLUTIONS.length - 1 : 0;

Does it make sense to always start at zero?
The icons of smaller size will never be used, will they?
Thus it's safe to start at the index which corresponds to the requested size if `size` matches, or the index such as `ICON_RESOLUTIONS[index] < size && ICON_RESOLUTIONS[index + 1] > size`.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1149:

> 1147:             int increment = size > MAX_QUALITY_ICON ? -1 : 1;
> 1148:             int end = size > MAX_QUALITY_ICON ? -1 : ICON_RESOLUTIONS.length;
> 1149:             for (int i = start; i != end; i+=increment) {

Suggestion:

            for (int i = start; i != end; i += increment) {

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1422:

> 1420:             int w = (int) width;
> 1421:             int retindex = 0;
> 1422:             for (Integer i: resolutionVariants.keySet()) {

Suggestion:

            for (Integer i : resolutionVariants.keySet()) {

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

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

From serb at openjdk.java.net  Wed Mar 10 23:16:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Mar 2021 23:16:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
Message-ID: <VusxzA_z8Nb8c148-tKmVMcV4lMSH5OEYOKGVoefiuQ=.7d03e27d-7259-431d-873c-00fce7a76b90@github.com>

On Sat, 27 Feb 2021 18:33:52 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe

Marked as reviewed by serb (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Thu Mar 11 04:27:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 11 Mar 2021 04:27:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in
 java/awt/font/TextJustifier.java justify
In-Reply-To: <dNsNq4A92M76X9DxGoNy2MRtEWmySjzTqXGEW4nNf0Y=.a2cef167-6287-42d9-8313-248c7d25d8d9@github.com>
References: <fY0ZM20o_3k5AyBaahIMnsWvKN-S2EHO4FR1hRkvzQM=.f745ba0c-19f0-4129-b3da-5c6748973ccc@github.com>
 <VLkXFIeLylWzWQI-oDdbsBygj4wyJRFzVR_bupAkNoY=.c509f2c2-f9d9-42aa-b476-16447f2bf4ee@github.com>
 <x8I0ycHMlatXczQ7XcmGUCHAvDLTmHiR4OvD26qBGs4=.edb854a1-789c-4a20-8c37-d5d6dc916f7b@github.com>
 <dNsNq4A92M76X9DxGoNy2MRtEWmySjzTqXGEW4nNf0Y=.a2cef167-6287-42d9-8313-248c7d25d8d9@github.com>
Message-ID: <LAHZT7WQO3RR3LTP3JEjyTDt-107Bf3-wAi-4Tpg_C0=.e84f0106-6843-41c1-9376-dea3e23164b5@github.com>

On Wed, 10 Mar 2021 18:48:50 GMT, Phil Race <prr at openjdk.org> wrote:

>> Hi, I am not sure about the  weight > 0  check ; weight is initialized with 0:   weight = 0;   and later some values are potentially added up to weight:   weight += gi.weight;
>> I am not sure about those gi.weight values, maybe they can be negative too ?
>
> Nothing throws an exception or otherwise prevent this being negative but that would be a weird usage. Typically the weight is either zero or based on the font size .. which ought not to be negative but I don't think anything prevents it and I think we would treat it essentially as a transform. So If you really want to be careful here, then yes assume weight could be negative.

By that same logic, then shouldn't absorbweight also be checked as != 0 instead of > 0 as that also uses += gi.weight

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

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

From mbaesken at openjdk.java.net  Thu Mar 11 06:48:10 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 11 Mar 2021 06:48:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in
 java/awt/font/TextJustifier.java justify
In-Reply-To: <LAHZT7WQO3RR3LTP3JEjyTDt-107Bf3-wAi-4Tpg_C0=.e84f0106-6843-41c1-9376-dea3e23164b5@github.com>
References: <fY0ZM20o_3k5AyBaahIMnsWvKN-S2EHO4FR1hRkvzQM=.f745ba0c-19f0-4129-b3da-5c6748973ccc@github.com>
 <VLkXFIeLylWzWQI-oDdbsBygj4wyJRFzVR_bupAkNoY=.c509f2c2-f9d9-42aa-b476-16447f2bf4ee@github.com>
 <x8I0ycHMlatXczQ7XcmGUCHAvDLTmHiR4OvD26qBGs4=.edb854a1-789c-4a20-8c37-d5d6dc916f7b@github.com>
 <dNsNq4A92M76X9DxGoNy2MRtEWmySjzTqXGEW4nNf0Y=.a2cef167-6287-42d9-8313-248c7d25d8d9@github.com>
 <LAHZT7WQO3RR3LTP3JEjyTDt-107Bf3-wAi-4Tpg_C0=.e84f0106-6843-41c1-9376-dea3e23164b5@github.com>
Message-ID: <rvIRdapzzfblnx_IN4U5OVYg-XV9tvpRnWvXv4ebrEs=.68e0af14-5ac7-48e5-965d-e0be25f03f34@github.com>

On Thu, 11 Mar 2021 04:24:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Nothing throws an exception or otherwise prevent this being negative but that would be a weird usage. Typically the weight is either zero or based on the font size .. which ought not to be negative but I don't think anything prevents it and I think we would treat it essentially as a transform. So If you really want to be careful here, then yes assume weight could be negative.
>
> By that same logic, then shouldn't absorbweight also be checked as != 0 instead of > 0 as that also uses += gi.weight

Hi, I am not sure about the absorbweight  check; but  currently the calculated value weightedAbsorb is only used when absorbing is true. And  there the > 0 check is present too

boolean absorbing = hitLimit && absorbweight > 0;

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

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

From avu at openjdk.java.net  Thu Mar 11 07:43:34 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 11 Mar 2021 07:43:34 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v12]
In-Reply-To: <OwqKVRF3i72HyNbRK4ljD--kQX0Jdszyfe3CbeDRsrI=.494c5b84-dc8d-4e1c-b647-48fd8ae5b03e@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <OwqKVRF3i72HyNbRK4ljD--kQX0Jdszyfe3CbeDRsrI=.494c5b84-dc8d-4e1c-b647-48fd8ae5b03e@github.com>
Message-ID: <T5hRLqVtqqsgQ7vqTa5rqmFi8BZvFwHaYl8QL093q4U=.e4cd393d-a415-4f4f-a472-9155c511ec5f@github.com>

On Wed, 10 Mar 2021 10:51:08 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 45 additional commits since the last revision:
> 
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#206 - 8262729 - aghaisas
>  - ... and 35 more: https://git.openjdk.java.net/jdk/compare/59142f88...3980ecbd

Marked as reviewed by avu (no project role).

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

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

From psadhukhan at openjdk.java.net  Thu Mar 11 10:16:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 11 Mar 2021 10:16:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263362: Avoid division by 0 in
 java/awt/font/TextJustifier.java justify
In-Reply-To: <rvIRdapzzfblnx_IN4U5OVYg-XV9tvpRnWvXv4ebrEs=.68e0af14-5ac7-48e5-965d-e0be25f03f34@github.com>
References: <fY0ZM20o_3k5AyBaahIMnsWvKN-S2EHO4FR1hRkvzQM=.f745ba0c-19f0-4129-b3da-5c6748973ccc@github.com>
 <VLkXFIeLylWzWQI-oDdbsBygj4wyJRFzVR_bupAkNoY=.c509f2c2-f9d9-42aa-b476-16447f2bf4ee@github.com>
 <x8I0ycHMlatXczQ7XcmGUCHAvDLTmHiR4OvD26qBGs4=.edb854a1-789c-4a20-8c37-d5d6dc916f7b@github.com>
 <dNsNq4A92M76X9DxGoNy2MRtEWmySjzTqXGEW4nNf0Y=.a2cef167-6287-42d9-8313-248c7d25d8d9@github.com>
 <LAHZT7WQO3RR3LTP3JEjyTDt-107Bf3-wAi-4Tpg_C0=.e84f0106-6843-41c1-9376-dea3e23164b5@github.com>
 <rvIRdapzzfblnx_IN4U5OVYg-XV9tvpRnWvXv4ebrEs=.68e0af14-5ac7-48e5-965d-e0be25f03f34@github.com>
Message-ID: <DCvgXIF9FnaixDy5Mk_CiwK_wDW0Sf7MSLOaycBhF1o=.4a5313a5-bf38-4c71-9437-42366e3caf2a@github.com>

On Thu, 11 Mar 2021 06:45:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> By that same logic, then shouldn't absorbweight also be checked as != 0 instead of > 0 as that also uses += gi.weight
>
> Hi, I am not sure about the absorbweight  check; but  currently the calculated value weightedAbsorb is only used when absorbing is true. And  there the > 0 check is present too
> 
> boolean absorbing = hitLimit && absorbweight > 0;

I meant that since we are dividing by weight and absorbweight 
` weightedDelta = delta / weight;`
and
 weightedAbsorb = (delta - gslimit) / absorbweight;
where both weight and absorbweight uses += gi.weight values so if one is checking for >0 
then to be consistent, in my opinion, 
other one should be same or absorbweight also probably should check !=0.

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

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

From psadhukhan at openjdk.java.net  Thu Mar 11 10:43:10 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 11 Mar 2021 10:43:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
Message-ID: <gdYag0rM8zT910Hs8e6elBe5vxlZsftjIstgySOEn-g=.70f847a3-9bfb-4de9-9cf5-cbe0e4bc22a1@github.com>

On Wed, 10 Mar 2021 15:38:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented polling for remote printers.
> That bug description also mentions watching the registry for changes and links to the article which describes the method yet it does so in terms of WMI. Using WMI is not necessary to watch for the registry updates.
> 
> It is possible to replace polling mechanism with registry change notifications. If the registry at `HKCU\Printers\Connections` is updated, refresh the list of print services.
> 
> It works perfectly well in my own testing with sharing a Generic / Text Only printer from another laptop. The notification comes as soon as the printer is installed, it results in a new key created under `Connections`. If a remote printer is removed, the notification is also triggered as the key corresponding to that printer is removed from the registry.
> 
> I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`.

src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp line 259:

> 257:                                                          NULL,
> 258:                                                          FALSE);
> 259:         if (keepMonitoring) {

I guess having "FALSE" as fAsynchronous  value mean the function does not return until a change has occurred so do we still need this do-while monitoring loop? And if the function fails once, should we stop monitoring?

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

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

From aivanov at openjdk.java.net  Thu Mar 11 10:57:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 11 Mar 2021 10:57:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <gdYag0rM8zT910Hs8e6elBe5vxlZsftjIstgySOEn-g=.70f847a3-9bfb-4de9-9cf5-cbe0e4bc22a1@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <gdYag0rM8zT910Hs8e6elBe5vxlZsftjIstgySOEn-g=.70f847a3-9bfb-4de9-9cf5-cbe0e4bc22a1@github.com>
Message-ID: <1JslPPm4UVa_ZCLCTMlTj7osfSYbLTxiNZYch71j9ro=.83f0ffee-150a-46f3-92f6-fdb6a83ad96f@github.com>

On Thu, 11 Mar 2021 10:39:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I guess having "FALSE" as fAsynchronous value mean the function does not return until a change has occurred so do we still need this do-while monitoring loop?

You're right, `FALSE` for `fAsynchronous` means the function doesn't return until a change occurred.

If a change occurs, we refresh the list of print services and then start to wait again. If we exit the loop, we'll not catch other changes that may occur.

> And if the function fails once, should we stop monitoring?
I followed Sergey's approach in `notifyLocalPrinterChange`, namely if `FindNextPrinterChangeNotification` returns an error, we quit the loop.

I can't see how we can fix the error if it occurs. Will it succeed the next time? Probably not. Thus I decided to quit the loop in case of an error.

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

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

From psadhukhan at openjdk.java.net  Thu Mar 11 11:34:23 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 11 Mar 2021 11:34:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <1JslPPm4UVa_ZCLCTMlTj7osfSYbLTxiNZYch71j9ro=.83f0ffee-150a-46f3-92f6-fdb6a83ad96f@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <gdYag0rM8zT910Hs8e6elBe5vxlZsftjIstgySOEn-g=.70f847a3-9bfb-4de9-9cf5-cbe0e4bc22a1@github.com>
 <1JslPPm4UVa_ZCLCTMlTj7osfSYbLTxiNZYch71j9ro=.83f0ffee-150a-46f3-92f6-fdb6a83ad96f@github.com>
Message-ID: <QEC6vRTgsUETeW0Ui1n7LriRSuwhSNzLj7t0wluypdY=.5d0a7ebc-f814-414a-beca-494a08e9c683@github.com>

On Thu, 11 Mar 2021 10:54:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp line 259:
>> 
>>> 257:                                                          NULL,
>>> 258:                                                          FALSE);
>>> 259:         if (keepMonitoring) {
>> 
>> I guess having "FALSE" as fAsynchronous  value mean the function does not return until a change has occurred so do we still need this do-while monitoring loop? And if the function fails once, should we stop monitoring?
>
>> I guess having "FALSE" as fAsynchronous value mean the function does not return until a change has occurred so do we still need this do-while monitoring loop?
> 
> You're right, `FALSE` for `fAsynchronous` means the function doesn't return until a change occurred.
> 
> If a change occurs, we refresh the list of print services and then start to wait again. If we exit the loop, we'll not catch other changes that may occur.
> 
>> And if the function fails once, should we stop monitoring?
> I followed Sergey's approach in `notifyLocalPrinterChange`, namely if `FindNextPrinterChangeNotification` returns an error, we quit the loop.
> 
> I can't see how we can fix the error if it occurs. Will it succeed the next time? Probably not. Thus I decided to quit the loop in case of an error.

I also am not sure on this. But I think since this is for remote printer, sometimes network availability issue might be there so it may fail more compared to local printer so I guess we should give this method a fair chance, more than that of local printer change, and not bail out on one failure.....maybe try out after some duration...or 5 times spaced out...as you did for the other EnumPrinter fix..

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

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

From akozlov at openjdk.java.net  Thu Mar 11 14:07:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 11 Mar 2021 14:07:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v23]
In-Reply-To: <SaFPzYzpXuZFUYhDvGg6PQHM-EUrSqbR02H5SzL6OvI=.77d3186b-74a5-404a-950f-95af6a13dabd@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
 <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>
 <SaFPzYzpXuZFUYhDvGg6PQHM-EUrSqbR02H5SzL6OvI=.77d3186b-74a5-404a-950f-95af6a13dabd@github.com>
Message-ID: <5oHOwsaj5Jpg7ukRTFk7MG--w0_bq2qSwH6FN0WOZNY=.e519c482-ba19-4e24-955d-07743ab92359@github.com>

On Wed, 3 Mar 2021 15:57:13 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 207:
>> 
>>> 205:   // Enable WXWrite: this function is called by the signal handler at arbitrary
>>> 206:   // point of execution.
>>> 207:   ThreadWXEnable wx(WXWrite, thread);
>> 
>> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform:
>> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) :
>>     _thread(thread ? thread : Thread::current()),`
>> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check.
>
>> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform:
>> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ? thread : Thread::current()),`
>> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check.
> 
> https://bugs.openjdk.java.net/browse/JDK-8262903 tracks this issue.

Thanks for report and analysis! I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576

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

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

From akozlov at openjdk.java.net  Thu Mar 11 14:07:43 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 11 Mar 2021 14:07:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v25]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  8262903: [macos_aarch64] Thread::current() called on detached thread

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/a72f6834..f6fb01b2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=23-24

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

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

From aivanov at openjdk.java.net  Thu Mar 11 14:53:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 11 Mar 2021 14:53:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <QEC6vRTgsUETeW0Ui1n7LriRSuwhSNzLj7t0wluypdY=.5d0a7ebc-f814-414a-beca-494a08e9c683@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <gdYag0rM8zT910Hs8e6elBe5vxlZsftjIstgySOEn-g=.70f847a3-9bfb-4de9-9cf5-cbe0e4bc22a1@github.com>
 <1JslPPm4UVa_ZCLCTMlTj7osfSYbLTxiNZYch71j9ro=.83f0ffee-150a-46f3-92f6-fdb6a83ad96f@github.com>
 <QEC6vRTgsUETeW0Ui1n7LriRSuwhSNzLj7t0wluypdY=.5d0a7ebc-f814-414a-beca-494a08e9c683@github.com>
Message-ID: <LFIP8CYebS0j9KyZHkQoKtX2__ws_wBfRLk6hiVPpcY=.2b080b4f-39e0-4a2c-ba16-3603c51c48a9@github.com>

On Thu, 11 Mar 2021 11:30:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> I guess having "FALSE" as fAsynchronous value mean the function does not return until a change has occurred so do we still need this do-while monitoring loop?
>> 
>> You're right, `FALSE` for `fAsynchronous` means the function doesn't return until a change occurred.
>> 
>> If a change occurs, we refresh the list of print services and then start to wait again. If we exit the loop, we'll not catch other changes that may occur.
>> 
>>> And if the function fails once, should we stop monitoring?
>> I followed Sergey's approach in `notifyLocalPrinterChange`, namely if `FindNextPrinterChangeNotification` returns an error, we quit the loop.
>> 
>> I can't see how we can fix the error if it occurs. Will it succeed the next time? Probably not. Thus I decided to quit the loop in case of an error.
>
> I also am not sure on this. But I think since this is for remote printer, sometimes network availability issue might be there so it may fail more compared to local printer so I guess we should give this method a fair chance, more than that of local printer change, and not bail out on one failure.....maybe try out after some duration...or 5 times spaced out...as you did for the other EnumPrinter fix..

No, network connectivity cannot affect this. The function watches for registry changes, specifically keys created or removed under `HKCU\Printers\Connections`. If network is down, you won't be able to add a new printer. Yet you can still remove an existing printer.

The case with `EnumPrinters` is very different. A printer may be renamed or a new printer may be added therefore the allocated buffer becomes to small to fit the updated data. Thus retrying with larger buffer makes perfect sense.

In this case, `RegNotifyChangeKeyValue` could fail only because of invalid parameters. If it does, it will fail on the retry because the parameters haven't changed.

In that sense, it's the same as with local printers. If the wait/notification function fails the first time, it will likely fail the second time and so on?

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

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

From aivanov at openjdk.java.net  Thu Mar 11 15:03:07 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 11 Mar 2021 15:03:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
Message-ID: <425OYVrQ8UldCi_4u-C5Q1RiYJJr5lrCT4mOmO-CDG4=.53915594-664a-4971-b04d-5097cec69028@github.com>

On Wed, 10 Mar 2021 15:38:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented polling for remote printers.
> That bug description also mentions watching the registry for changes and links to the article which describes the method yet it does so in terms of WMI. Using WMI is not necessary to watch for the registry updates.
> 
> It is possible to replace polling mechanism with registry change notifications. If the registry at `HKCU\Printers\Connections` is updated, refresh the list of print services.
> 
> It works perfectly well in my own testing with sharing a Generic / Text Only printer from another laptop. The notification comes as soon as the printer is installed, it results in a new key created under `Connections`. If a remote printer is removed, the notification is also triggered as the key corresponding to that printer is removed from the registry.
> 
> I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`.

src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp line 258:

> 256:                                                          REG_NOTIFY_CHANGE_NAME,
> 257:                                                          NULL,
> 258:                                                          FALSE);

[`RegNotifyChangeKeyValue`](https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regnotifychangekeyvalue) notifies the caller about changes to the attributes or contents of a specified registry key.

? `hKey`: A handle to `HKEY_CURRENT_USER\Printers\Connections` key which is opened above.
? `bWatchSubtree = TRUE`: The function reports changes in the specified key and its subkeys.
? `dwNotifyFilter = REG_NOTIFY_CHANGE_NAME`: Notify the caller if a subkey is added or deleted.
? `hEvent = NULL`: If `fAsynchronous` is FALSE, `hEvent` is ignored.
? `fAsynchronous = FALSE`: The function does not return until a change has occurred.

When a new remote printer is added, a new key is created under `HKCU\Printers\Connections`; when an existing remote printer is removed, the key below `Connections` is removed; no values are added or removed in `Connections` key, thus `REG_NOTIFY_CHANGE_LAST_SET` filter is not needed.

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

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

From avu at openjdk.java.net  Thu Mar 11 16:53:12 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 11 Mar 2021 16:53:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <PZSsyAQ4ras6jBm4u-FrY8hlo5llqxPgxP_VauEmm3Y=.9862cc2c-904f-4915-9337-721767493f20@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
 <vTEnRF92PmLsXlO-aHLfbQrs7Ao7mbhQ3y-zpDywaXg=.820a264c-c765-4bdb-a65a-9787eba1681f@github.com>
 <PZSsyAQ4ras6jBm4u-FrY8hlo5llqxPgxP_VauEmm3Y=.9862cc2c-904f-4915-9337-721767493f20@github.com>
Message-ID: <qkHNKzF5_hpcHEaAldCZDcDdTjySRyQlTYQtRxqwVQw=.87b32878-ab06-49a2-8762-0a3888b0db10@github.com>

On Tue, 9 Mar 2021 23:15:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Also, MTLSD_WINDOW is supported
>
> How it is used? Can we really draw to the window directly? It looks like it copied from the OGL where it is unused since CLayer integration. Something is inconsistent here.

Here is a follow-up issue JDK-8263463

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

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

From aghaisas at openjdk.java.net  Thu Mar 11 17:54:16 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 11 Mar 2021 17:54:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v12]
In-Reply-To: <J1-dSmk1I83VAmaOAcG5ETCGSud-NK807s1squvqMMA=.08f5e156-d92d-4fc2-945f-4f3b89d9624f@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <8YBuOeDAPN2osBnW5cyN-91hYtg7malBqDlJZsgWrPk=.6c99ab50-76a8-4686-85dd-5918abfdacf0@github.com>
 <J1-dSmk1I83VAmaOAcG5ETCGSud-NK807s1squvqMMA=.08f5e156-d92d-4fc2-945f-4f3b89d9624f@github.com>
Message-ID: <wH1XmE6WBn07al20QgTWc_X3t7kr6lqsdz9bg-DVSGc=.3ca42635-78ca-47db-bc34-8c046c7f1094@github.com>

On Mon, 8 Feb 2021 18:47:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 82:
>> 
>>> 80:     (JNIEnv *env, jclass mtlgc)
>>> 81: {
>>> 82:     FILE *f = popen("/usr/sbin/system_profiler SPDisplaysDataType", "r");
>> 
>> How robust is this? It seems like the contents of this could be an implementation detail and subject to change. Is it documented by Apple?
>
> I suggest fixing this before the integration.

Fixed with JDK-8259825.

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

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

From aghaisas at openjdk.java.net  Thu Mar 11 18:00:15 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 11 Mar 2021 18:00:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

Ajit Ghaisas 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 47 additional commits since the last revision:

 - Lanai PR#214 - 8263324 - avu
 - Merge branch 'master' into 8260931_lanai_JEP_branch
 - Lanai PR#213 - 8263325 - avu
 - Lanai PR#212 - 8259825 - aghaisas
 - Lanai PR#211 - 8262882 - aghaisas
 - Merge branch 'master' into 8260931_lanai_JEP_branch
 - Lanai PR#210 - 8263159 - jdv
 - Lanai PR#209 - 8262936 - jdv
 - Lanai PR#208 - 8262928 - jdv
 - Lanai PR#207 - 8262750 - jdv
 - ... and 37 more: https://git.openjdk.java.net/jdk/compare/1c8fee73...369c3d21

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/3980ecbd..369c3d21

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=11-12

  Stats: 2420 lines in 128 files changed: 1246 ins; 368 del; 806 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

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

From aghaisas at openjdk.java.net  Thu Mar 11 18:10:23 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 11 Mar 2021 18:10:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v12]
In-Reply-To: <T5hRLqVtqqsgQ7vqTa5rqmFi8BZvFwHaYl8QL093q4U=.e4cd393d-a415-4f4f-a472-9155c511ec5f@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <OwqKVRF3i72HyNbRK4ljD--kQX0Jdszyfe3CbeDRsrI=.494c5b84-dc8d-4e1c-b647-48fd8ae5b03e@github.com>
 <T5hRLqVtqqsgQ7vqTa5rqmFi8BZvFwHaYl8QL093q4U=.e4cd393d-a415-4f4f-a472-9155c511ec5f@github.com>
Message-ID: <oekv8-XLWUfqSW4IiGfnnIAOWhGCUb9RMMoKT8nAmUE=.d87f50a7-a4c9-4fb5-afe1-e0d0db677645@github.com>

On Thu, 11 Mar 2021 07:40:47 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Ajit Ghaisas 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 45 additional commits since the last revision:
>> 
>>  - Lanai PR#213 - 8263325 - avu
>>  - Lanai PR#212 - 8259825 - aghaisas
>>  - Lanai PR#211 - 8262882 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#210 - 8263159 - jdv
>>  - Lanai PR#209 - 8262936 - jdv
>>  - Lanai PR#208 - 8262928 - jdv
>>  - Lanai PR#207 - 8262750 - jdv
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#206 - 8262729 - aghaisas
>>  - ... and 35 more: https://git.openjdk.java.net/jdk/compare/d1e5ff8f...3980ecbd
>
> Marked as reviewed by avu (no project role).

We have addressed the review comments (except for a few minor follow-on issues)
This version of the PR is the one which we are planning to integrate into the JDK. Please review and approve.

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

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

From shade at openjdk.java.net  Thu Mar 11 19:20:24 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 11 Mar 2021 19:20:24 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263467: Incorrect double-checked locking
 in sun.java2d.CRenderer
Message-ID: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>

SonarCloud reports multiple incorrect double-checked locking cases in `sun.java2d.CRenderer`. For example:

  Arc2D arcToShape;

  ...
            if (arcToShape == null) {
                synchronized (this) {
                    if (arcToShape == null) {
                        arcToShape = new Arc2D.Float();
                    }
                }
            }

`Arc2D` contains fields that are not `final`. `arcToShape` is not `volatile`. This makes it an incorrect DCL.
This code is used by Mac OS, do it would probably blow up some time later on M1.

This is the candidate fix that preserves the semantics. I am doing this fix blindly so far, without testing on real Mac OS. But maybe there is no need to do any of this, because the setter methods overwrite the contents of all these objects under their own sync. So, maybe we can just allocate those objects without DCL-backed caching and pass them in?

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

Commit messages:
 - JDK-8263467: Incorrect double-checked locking in sun.java2d.CRenderer

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

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

From prr at openjdk.java.net  Thu Mar 11 19:45:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 11 Mar 2021 19:45:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
Message-ID: <aOiARP23NNRt8eOMkw_6YB6W2Z1oJKapNWeRRs76DoE=.1fe02c10-07ef-4004-9b3d-f5e598a20a2a@github.com>

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 47 additional commits since the last revision:
> 
>  - Lanai PR#214 - 8263324 - avu
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/ada1a022...369c3d21

Marked as reviewed by prr (Reviewer).

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

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

From stefank at openjdk.java.net  Thu Mar 11 20:31:16 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 11 Mar 2021 20:31:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v25]
In-Reply-To: <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
Message-ID: <gKoH7dS4tYmoRme7Wzbg1mH0ygHFKlaTQgS_JiIE_8A=.96b62223-ef50-43f5-9db1-d150e449e1b9@github.com>

On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262903: [macos_aarch64] Thread::current() called on detached thread

Marked as reviewed by stefank (Reviewer).

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

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

From stefank at openjdk.java.net  Thu Mar 11 20:31:17 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 11 Mar 2021 20:31:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v12]
In-Reply-To: <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
 <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>
Message-ID: <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com>

On Tue, 9 Mar 2021 17:55:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.cpp line 2515:
>> 
>>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) {
>>> 2514:   // Enable WXWrite: called directly from interpreter native wrapper.
>>> 2515:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread));
>> 
>> FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version:
>> ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) {
>>   MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {}
>> void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp)
>> With that said, I'm fine with taking this discussion as a follow-up.
>
> The former version used no such macros. I like that now it's clear the W^X management is relevant to macos/aarch64 only. I see the point to move the pre-processor condition into the class implementation. But I think it will bring a bit of inconsistency, as the rest of W^X implementation is explicitly guarded by preprocessor conditionals. I've also tried to push macro conditionals as far as possible down to implementation, providing a kind of generalized W^X interface. That required a few artificial decisions, e.g. how would we call the mode we execute on the rest of platforms with write and execute allowed, WXWriteExec?.. I abandoned that attempt.

I think we would use the same names, but I haven't given it more thought. I might take a look at this after this has been integrated.

>> src/hotspot/share/runtime/thread.hpp line 848:
>> 
>>> 846:   void init_wx();
>>> 847:   WXMode enable_wx(WXMode new_state);
>>> 848: #endif // __APPLE__ && AARCH64
>> 
>> Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions.
>
> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. 
> 
> In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR.

Good point about Thread vs JavaThread. Yes, this can be looked into as follow-up cleanups.

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

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

From kcr at openjdk.java.net  Fri Mar 12 00:13:38 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 12 Mar 2021 00:13:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
Message-ID: <m93M5wjxtdAdMx0Qe7pg8mX8be4xwyWF2FaaIQx5ixk=.66eac4af-6f2b-416a-a565-742e4ccfe350@github.com>

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 47 additional commits since the last revision:
> 
>  - Lanai PR#214 - 8263324 - avu
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/204b2bcc...369c3d21

Latest changes look good. I confirmed that this PR has all of the content from the lanai repo.

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

Marked as reviewed by kcr (Author).

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

From serb at openjdk.java.net  Fri Mar 12 01:14:36 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 01:14:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
Message-ID: <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 47 additional commits since the last revision:
> 
>  - Lanai PR#214 - 8263324 - avu
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/5e61bf57...369c3d21

src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 323:

> 321:      * more code just to support a few uncommon cases.
> 322:      */
> 323:     public boolean canRenderLCDText(SunGraphics2D sg2d) {

Just curious, can we render LCD on 10.14+ via metal? Does it work fine?

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTSurfaceLayers.m line 73:

> 71: // Updates back buffer size of the layer if it's an OpenGL/Metal layer
> 72: // including all OpenGL/Metal sublayers
> 73: + (void) repaintLayersRecursively:(CALayer*)aLayer {

The operation of this code is still being investigated.  @prsadhuk please add a bugid here.

src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 148:

> 146:         rq.lock();
> 147:         try {
> 148:             // getMTLConfigInfo() creates and destroys temporary

Does it really create and destroy temporary surfaces/contexts?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLPaints.m line 813:

> 811:     initTemplatePipelineDescriptors();
> 812:     // This block is not reached in current implementation.
> 813:     // Texture paint XOR mode rendering uses a tile based rendering using a SW pipe (similar to OGL)

Do we have a bugid to implement this later?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h line 59:

> 57:  * The offset in pixels of the Metal viewport origin from the lower-left
> 58:  * corner of the heavyweight drawable.  For example, a top-level frame on
> 59:  * Windows XP has lower-left insets of (4,4).  The Metal viewport origin

Do we really use these fields? "Windows XP"??

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

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

From serb at openjdk.java.net  Fri Mar 12 01:14:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 01:14:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <vTEnRF92PmLsXlO-aHLfbQrs7Ao7mbhQ3y-zpDywaXg=.820a264c-c765-4bdb-a65a-9787eba1681f@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
 <vTEnRF92PmLsXlO-aHLfbQrs7Ao7mbhQ3y-zpDywaXg=.820a264c-c765-4bdb-a65a-9787eba1681f@github.com>
Message-ID: <JkDmLQYWsGlncXd5L7DOgEKhzV5S8lTVlfAUBQGRc4U=.d5b7e4d3-1831-417f-8ce0-b886966ac1f2@github.com>

On Tue, 9 Mar 2021 20:16:25 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLBlitLoops.java line 499:
>> 
>>> 497:         }
>>> 498: 
>>> 499:         // We can convert argb_pre data from MTL surface in two places:
>> 
>> Does anybody check that this is true for the metal pipeline? or It is just copied from the OGL?
>
> I fixed some conversion logic within JDK-8256331.

OK, just to confirm. I wrote that text for OGL because it was the fastest way to transfer+convert the data from the video card to the memory. And as far as I understand the metal has the same limitation? It is not possible to convert it to some non-ARGB/Pre format on the fly while transferring the pixles?

>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 146:
>> 
>>> 144:                 return MTLSurfaceRTT;
>>> 145:             default:
>>> 146:                 return MTLSurface;
>> 
>> Do we really support 3 different types of surface? I guess only two of them are different: textures used for manageable images, and surfaces used by the volatile image.
>
> It's true but I don't see any problem returning a more generic type as a default here

tbd

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

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

From serb at openjdk.java.net  Fri Mar 12 01:14:37 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 01:14:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <JbULJPOJ13dlGD0pH_H6B_0LnCGLah9ll8QSPzs4BAs=.f3eee656-1574-4bd4-9321-7ad29dd08739@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
 <JbULJPOJ13dlGD0pH_H6B_0LnCGLah9ll8QSPzs4BAs=.f3eee656-1574-4bd4-9321-7ad29dd08739@github.com>
Message-ID: <CdN09GlPeWSliY6uDElilkfCTN4Oyw1PFaMkhg8qHzw=.331d1f1e-5f34-46ca-8d95-1c9351b1c421@github.com>

On Wed, 10 Mar 2021 11:43:43 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CWarningWindow.java line 304:
>> 
>>> 302:                 };
>>> 303:             }
>>> 304:             public MTLLayer createMTLLayer() {
>> 
>> TODO to test that this functionality works
>
> Testing was done under JDK-8261141.

JDK-8261630

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

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

From jdv at openjdk.java.net  Fri Mar 12 02:33:25 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 12 Mar 2021 02:33:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
 <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>
Message-ID: <jE_GTtI6UmF4rUKIHg4COJZuuWDwJ9zCcdx7S5LkETw=.ef840ad4-cdca-4d8e-827e-f32c6c23d0e6@github.com>

On Fri, 12 Mar 2021 00:42:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 47 additional commits since the last revision:
>> 
>>  - Lanai PR#214 - 8263324 - avu
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#213 - 8263325 - avu
>>  - Lanai PR#212 - 8259825 - aghaisas
>>  - Lanai PR#211 - 8262882 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#210 - 8263159 - jdv
>>  - Lanai PR#209 - 8262936 - jdv
>>  - Lanai PR#208 - 8262928 - jdv
>>  - Lanai PR#207 - 8262750 - jdv
>>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/53b0bea8...369c3d21
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 323:
> 
>> 321:      * more code just to support a few uncommon cases.
>> 322:      */
>> 323:     public boolean canRenderLCDText(SunGraphics2D sg2d) {
> 
> Just curious, can we render LCD on 10.14+ via metal? Does it work fine?

Yes Sergey it works fine in 10.14+ systems via metal. Most of the JCK manual tests use LCD text on UI Components and it is recently verified in 10.14+ systems for EA10.

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

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

From serb at openjdk.java.net  Fri Mar 12 02:53:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 02:53:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <jE_GTtI6UmF4rUKIHg4COJZuuWDwJ9zCcdx7S5LkETw=.ef840ad4-cdca-4d8e-827e-f32c6c23d0e6@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
 <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>
 <jE_GTtI6UmF4rUKIHg4COJZuuWDwJ9zCcdx7S5LkETw=.ef840ad4-cdca-4d8e-827e-f32c6c23d0e6@github.com>
Message-ID: <ZIHvDdoUouMeLdECi794Mflyc_dEX0cUFnEO1M6Bv7U=.a8c7959f-1766-4239-afb8-26b5848c7365@github.com>

On Fri, 12 Mar 2021 02:29:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 323:
>> 
>>> 321:      * more code just to support a few uncommon cases.
>>> 322:      */
>>> 323:     public boolean canRenderLCDText(SunGraphics2D sg2d) {
>> 
>> Just curious, can we render LCD on 10.14+ via metal? Does it work fine?
>
> Yes Sergey it works fine in 10.14+ systems via metal. Most of the JCK manual tests use LCD text on UI Components and it is recently verified in 10.14+ systems for EA10.

Ok, for some reason I thought that the new macOS stopped providing LCD glyphs.

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

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

From serb at openjdk.java.net  Fri Mar 12 03:22:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 03:22:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263467: Incorrect double-checked
 locking in sun.java2d.CRenderer
In-Reply-To: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>
References: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>
Message-ID: <zmmHhWjVPatEQUEtSBMUPHHU85LwF230DL0DabQPP-o=.56152a15-9d69-4611-b5d9-5d8caccab91f@github.com>

On Thu, 11 Mar 2021 19:13:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports multiple incorrect double-checked locking cases in `sun.java2d.CRenderer`. For example:
> 
>   Arc2D arcToShape;
> 
>   ...
>             if (arcToShape == null) {
>                 synchronized (this) {
>                     if (arcToShape == null) {
>                         arcToShape = new Arc2D.Float();
>                     }
>                 }
>             }
> 
> `Arc2D` contains fields that are not `final`. `arcToShape` is not `volatile`. This makes it an incorrect DCL.
> This code is used by Mac OS, do it would probably blow up some time later on M1.
> 
> This is the candidate fix that preserves the semantics. I am doing this fix blindly so far, without testing on real Mac OS. But maybe there is no need to do any of this, because the setter methods overwrite the contents of all these objects under their own sync. So, maybe we can just allocate those objects without DCL-backed caching and pass them in?

I guess "Incorrect double-checked" is a too strict description of this code, it just tried to eliminate the creation of one object and do not care about the content of that object, since it is immediately overridden. 

I think It will be more clear to just eliminate this DCL since overhead and code complexity seems too much to just cache five objects.

Probably it was important in past(jdk6 and below) when this renderer was used for onscreen rendering. Currently, it is used for printing(if actually used at all).

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

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

From serb at openjdk.java.net  Fri Mar 12 03:48:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 03:48:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <VusxzA_z8Nb8c148-tKmVMcV4lMSH5OEYOKGVoefiuQ=.7d03e27d-7259-431d-873c-00fce7a76b90@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
 <VusxzA_z8Nb8c148-tKmVMcV4lMSH5OEYOKGVoefiuQ=.7d03e27d-7259-431d-873c-00fce7a76b90@github.com>
Message-ID: <BLagWj6YqmJMNXqIzAzx4_sWmEm6rVB-RTxvhBiFwMg=.8da8c822-413d-4203-95ad-9f046fb8dfdd@github.com>

On Wed, 10 Mar 2021 23:13:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe
>
> Marked as reviewed by serb (Reviewer).

@prrace Do you have any objections to integrating this change?

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

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

From psadhukhan at openjdk.java.net  Fri Mar 12 04:17:24 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 04:17:24 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
 <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>
Message-ID: <Mr6l-o1EfB0bgMi6ghyDM_iwaLtJ4ODyK-mtxLXgF1Q=.3af75b74-bcca-4885-85f2-79aa609bfc8a@github.com>

On Fri, 12 Mar 2021 00:48:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 47 additional commits since the last revision:
>> 
>>  - Lanai PR#214 - 8263324 - avu
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#213 - 8263325 - avu
>>  - Lanai PR#212 - 8259825 - aghaisas
>>  - Lanai PR#211 - 8262882 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#210 - 8263159 - jdv
>>  - Lanai PR#209 - 8262936 - jdv
>>  - Lanai PR#208 - 8262928 - jdv
>>  - Lanai PR#207 - 8262750 - jdv
>>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/aca5b193...369c3d21
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTSurfaceLayers.m line 73:
> 
>> 71: // Updates back buffer size of the layer if it's an OpenGL/Metal layer
>> 72: // including all OpenGL/Metal sublayers
>> 73: + (void) repaintLayersRecursively:(CALayer*)aLayer {
> 
> The operation of this code is still being investigated.  @prsadhuk please add a bugid here.

JDK-8263485

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

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

From aghaisas at openjdk.java.net  Fri Mar 12 04:20:26 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 12 Mar 2021 04:20:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
 <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>
Message-ID: <Clu6pNmF68HcJW2UqAsRWfQXN4ls51bjw0ztC0DslKk=.563099a4-c221-458e-a9f3-a8698bb71f41@github.com>

On Fri, 12 Mar 2021 01:04:22 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 47 additional commits since the last revision:
>> 
>>  - Lanai PR#214 - 8263324 - avu
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#213 - 8263325 - avu
>>  - Lanai PR#212 - 8259825 - aghaisas
>>  - Lanai PR#211 - 8262882 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#210 - 8263159 - jdv
>>  - Lanai PR#209 - 8262936 - jdv
>>  - Lanai PR#208 - 8262928 - jdv
>>  - Lanai PR#207 - 8262750 - jdv
>>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/23f9642d...369c3d21
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLPaints.m line 813:
> 
>> 811:     initTemplatePipelineDescriptors();
>> 812:     // This block is not reached in current implementation.
>> 813:     // Texture paint XOR mode rendering uses a tile based rendering using a SW pipe (similar to OGL)
> 
> Do we have a bugid to implement this later?

This is not exactly a TODO which we intend to implement later. Hence, there is no bugid.
Metal does not support XOR mode rendering. I have kept this code as to know the code path to take in case we need to implement it in future.

> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h line 59:
> 
>> 57:  * The offset in pixels of the Metal viewport origin from the lower-left
>> 58:  * corner of the heavyweight drawable.  For example, a top-level frame on
>> 59:  * Windows XP has lower-left insets of (4,4).  The Metal viewport origin
> 
> Do we really use these fields? "Windows XP"??

This will be fixed as a follow-on issue - JDK-8263486.

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

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

From jayathirth.d.v at oracle.com  Fri Mar 12 04:41:05 2021
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Fri, 12 Mar 2021 04:41:05 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8260931: Implement JEP 382: New
 macOS Rendering Pipeline [v13]
In-Reply-To: <5BB55AA4-04ED-4B6B-BB89-61DDD5D7EB53@gmail.com>
References: <ZIHvDdoUouMeLdECi794Mflyc_dEX0cUFnEO1M6Bv7U=.a8c7959f-1766-4239-afb8-26b5848c7365@github.com>
 <5BB55AA4-04ED-4B6B-BB89-61DDD5D7EB53@gmail.com>
Message-ID: <31566D3F-22C4-4C12-96DC-E5158574C7D0@oracle.com>



> On 12-Mar-2021, at 9:29 AM, Scott Palmer <swpalmer at gmail.com> wrote:
> 
> 
>> On Mar 11, 2021, at 9:53 PM, Sergey Bylokhov <serb at openjdk.java.net> wrote:
>> 
>> ?On Fri, 12 Mar 2021 02:29:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:
>> 
>>>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 323:
>>>> 
>>>>> 321:      * more code just to support a few uncommon cases.
>>>>> 322:      */
>>>>> 323:     public boolean canRenderLCDText(SunGraphics2D sg2d) {
>>>> 
>>>> Just curious, can we render LCD on 10.14+ via metal? Does it work fine?
>>> 
>>> Yes Sergey it works fine in 10.14+ systems via metal. Most of the JCK manual tests use LCD text on UI Components and it is recently verified in 10.14+ systems for EA10.
>> 
>> Ok, for some reason I thought that the new macOS stopped providing LCD glyphs.
>> 
> 
> Are the glyphs different or just the way they are rasterized?
> 
> Newer versions of macOS don?t do LCD text and have gone back to plain grey-scale anti-aliasing. 
> Java 2D should default to NOT doing LCD anti-aliasing for text on macOS if it wants to fit in with the look of native applications. 
> (I?m not sure if that applies to non-retina displays.)
> 
By default we don?t do LCD anti-aliasing for text, only when we set Text Rendering Hint to use LCD antialiasing we take sub-pixel rendering path.
> Scott


From psadhukhan at openjdk.java.net  Fri Mar 12 04:58:12 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 04:58:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <425OYVrQ8UldCi_4u-C5Q1RiYJJr5lrCT4mOmO-CDG4=.53915594-664a-4971-b04d-5097cec69028@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <425OYVrQ8UldCi_4u-C5Q1RiYJJr5lrCT4mOmO-CDG4=.53915594-664a-4971-b04d-5097cec69028@github.com>
Message-ID: <1XWnbAUoXYd0shleNnct4uky2ZboVmUSvPJ5AXXsheM=.5bdbc41e-ab5b-4037-9872-7f4261d5a462@github.com>

On Thu, 11 Mar 2021 14:59:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> [JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented polling for remote printers.
>> That bug description also mentions watching the registry for changes and links to the article which describes the method yet it does so in terms of WMI. Using WMI is not necessary to watch for the registry updates.
>> 
>> It is possible to replace polling mechanism with registry change notifications. If the registry at `HKCU\Printers\Connections` is updated, refresh the list of print services.
>> 
>> It works perfectly well in my own testing with sharing a Generic / Text Only printer from another laptop. The notification comes as soon as the printer is installed, it results in a new key created under `Connections`. If a remote printer is removed, the notification is also triggered as the key corresponding to that printer is removed from the registry.
>> 
>> I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`.
>
> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp line 258:
> 
>> 256:                                                          REG_NOTIFY_CHANGE_NAME,
>> 257:                                                          NULL,
>> 258:                                                          FALSE);
> 
> [`RegNotifyChangeKeyValue`](https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regnotifychangekeyvalue) notifies the caller about changes to the attributes or contents of a specified registry key.
> 
> ? `hKey`: A handle to `HKEY_CURRENT_USER\Printers\Connections` key which is opened above.
> ? `bWatchSubtree = TRUE`: The function reports changes in the specified key and its subkeys.
> ? `dwNotifyFilter = REG_NOTIFY_CHANGE_NAME`: Notify the caller if a subkey is added or deleted.
> ? `hEvent = NULL`: If `fAsynchronous` is FALSE, `hEvent` is ignored.
> ? `fAsynchronous = FALSE`: The function does not return until a change has occurred.
> 
> When a new remote printer is added, a new key is created under `HKCU\Printers\Connections`; when an existing remote printer is removed, the key below `Connections` is removed; no values are added or removed in `Connections` key, thus `REG_NOTIFY_CHANGE_LAST_SET` filter is not needed.

Is this only about addition/removal? What about printer name change? Shouldn't we get notified in that case as trying to print on printer with old name will not find the printer!!
If yes, in that regard I guess REG_NOTIFY_CHANGE_LAST_SET is the one to go for as it states
`"Notify the caller of changes to a value of the key. This can include adding or deleting a value, or changing an existing value. "`

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

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

From psadhukhan at openjdk.java.net  Fri Mar 12 04:58:11 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 04:58:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <LFIP8CYebS0j9KyZHkQoKtX2__ws_wBfRLk6hiVPpcY=.2b080b4f-39e0-4a2c-ba16-3603c51c48a9@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <gdYag0rM8zT910Hs8e6elBe5vxlZsftjIstgySOEn-g=.70f847a3-9bfb-4de9-9cf5-cbe0e4bc22a1@github.com>
 <1JslPPm4UVa_ZCLCTMlTj7osfSYbLTxiNZYch71j9ro=.83f0ffee-150a-46f3-92f6-fdb6a83ad96f@github.com>
 <QEC6vRTgsUETeW0Ui1n7LriRSuwhSNzLj7t0wluypdY=.5d0a7ebc-f814-414a-beca-494a08e9c683@github.com>
 <LFIP8CYebS0j9KyZHkQoKtX2__ws_wBfRLk6hiVPpcY=.2b080b4f-39e0-4a2c-ba16-3603c51c48a9@github.com>
Message-ID: <zk-u7hsa1DmLlvyiAgu4iATCqiziDcE3239c52UYC14=.0b43867e-8146-4036-94af-3779bba3c6c4@github.com>

On Thu, 11 Mar 2021 14:49:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I also am not sure on this. But I think since this is for remote printer, sometimes network availability issue might be there so it may fail more compared to local printer so I guess we should give this method a fair chance, more than that of local printer change, and not bail out on one failure.....maybe try out after some duration...or 5 times spaced out...as you did for the other EnumPrinter fix..
>
> No, network connectivity cannot affect this. The function watches for registry changes, specifically keys created or removed under `HKCU\Printers\Connections`. If network is down, you won't be able to add a new printer. Yet you can still remove an existing printer.
> 
> The case with `EnumPrinters` is very different. A printer may be renamed or a new printer may be added therefore the allocated buffer becomes to small to fit the updated data. Thus retrying with larger buffer makes perfect sense.
> 
> In this case, `RegNotifyChangeKeyValue` could fail only because of invalid parameters. If it does, it will fail on the retry because the parameters haven't changed.
> 
> In that sense, it's the same as with local printers. If the wait/notification function fails the first time, it will likely fail the second time and so on?

Ok

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

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

From serb at openjdk.java.net  Fri Mar 12 05:00:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 05:00:30 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <m93M5wjxtdAdMx0Qe7pg8mX8be4xwyWF2FaaIQx5ixk=.66eac4af-6f2b-416a-a565-742e4ccfe350@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
 <m93M5wjxtdAdMx0Qe7pg8mX8be4xwyWF2FaaIQx5ixk=.66eac4af-6f2b-416a-a565-742e4ccfe350@github.com>
Message-ID: <wcoH38epi7Lqu4C_Z1cBZUEsgSWjCkXwtF5xWRUfVWg=.e17fe855-ab66-40c2-bd2c-1f4cb5c67fa2@github.com>

On Fri, 12 Mar 2021 00:09:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas 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 47 additional commits since the last revision:
>> 
>>  - Lanai PR#214 - 8263324 - avu
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#213 - 8263325 - avu
>>  - Lanai PR#212 - 8259825 - aghaisas
>>  - Lanai PR#211 - 8262882 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#210 - 8263159 - jdv
>>  - Lanai PR#209 - 8262936 - jdv
>>  - Lanai PR#208 - 8262928 - jdv
>>  - Lanai PR#207 - 8262750 - jdv
>>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/9d82be31...369c3d21
>
> Latest changes look good. I confirmed that this PR has all of the content from the lanai repo.

> By default we don?t do LCD anti-aliasing for text, only when we set Text Rendering Hint to use LCD antialiasing we take sub-pixel rendering path.

And it actually produces LCD glyphs? not the grayscale?

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

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

From jayathirth.d.v at oracle.com  Fri Mar 12 05:09:56 2021
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Fri, 12 Mar 2021 05:09:56 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: 8260931: Implement JEP 382: New
 macOS Rendering Pipeline [v13]
In-Reply-To: <wcoH38epi7Lqu4C_Z1cBZUEsgSWjCkXwtF5xWRUfVWg=.e17fe855-ab66-40c2-bd2c-1f4cb5c67fa2@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
 <m93M5wjxtdAdMx0Qe7pg8mX8be4xwyWF2FaaIQx5ixk=.66eac4af-6f2b-416a-a565-742e4ccfe350@github.com>
 <wcoH38epi7Lqu4C_Z1cBZUEsgSWjCkXwtF5xWRUfVWg=.e17fe855-ab66-40c2-bd2c-1f4cb5c67fa2@github.com>
Message-ID: <0C86C579-3AC4-4C0A-9B95-A9335276C4B2@oracle.com>



> On 12-Mar-2021, at 10:30 AM, Sergey Bylokhov <serb at openjdk.java.net> wrote:
> 
> On Fri, 12 Mar 2021 00:09:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:
> 
>>> Ajit Ghaisas 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 47 additional commits since the last revision:
>>> 
>>> - Lanai PR#214 - 8263324 - avu
>>> - Merge branch 'master' into 8260931_lanai_JEP_branch
>>> - Lanai PR#213 - 8263325 - avu
>>> - Lanai PR#212 - 8259825 - aghaisas
>>> - Lanai PR#211 - 8262882 - aghaisas
>>> - Merge branch 'master' into 8260931_lanai_JEP_branch
>>> - Lanai PR#210 - 8263159 - jdv
>>> - Lanai PR#209 - 8262936 - jdv
>>> - Lanai PR#208 - 8262928 - jdv
>>> - Lanai PR#207 - 8262750 - jdv
>>> - ... and 37 more: https://git.openjdk.java.net/jdk/compare/9d82be31...369c3d21
>> 
>> Latest changes look good. I confirmed that this PR has all of the content from the lanai repo.
> 
>> By default we don?t do LCD anti-aliasing for text, only when we set Text Rendering Hint to use LCD antialiasing we take sub-pixel rendering path.
> 
> And it actually produces LCD glyphs? not the grayscale?
We get glyphs which take more than a byte to represent each pixel.
Based on which we take LCD sub-pixel rendering path.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2403


From dholmes at openjdk.java.net  Fri Mar 12 05:27:17 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 12 Mar 2021 05:27:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v25]
In-Reply-To: <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
Message-ID: <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>

On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262903: [macos_aarch64] Thread::current() called on detached thread

src/hotspot/share/runtime/safefetch.inline.hpp line 35:

> 33: inline int SafeFetch32(int* adr, int errValue) {
> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));

I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.

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

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

From akozlov at openjdk.java.net  Fri Mar 12 07:12:17 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 07:12:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v25]
In-Reply-To: <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
 <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>
Message-ID: <lPoCNtc83YmZudBHHRDi_pc4xqoTTIzA0b-TzxQXV9o=.1754abd9-5747-4528-a040-0abf5ff6af35@github.com>

On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8262903: [macos_aarch64] Thread::current() called on detached thread
>
> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
> 
>> 33: inline int SafeFetch32(int* adr, int errValue) {
>> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));
> 
> I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.

I'm not sure about expected behavior then. We may crash trying to execute the generated code, since we may have no WXExec. If we switch to WXExec, we would need to go back to a previous W^X state, but we don't know which one without the thread.

BTW, the test passes, probably that's why it didn't get attention. All non-trivial actions in the current implementation of `pd_hotspot_signal_handler` (hhttps://github.com/openjdk/jdk/pull/2200/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40R215-R324) assume non-NULL thread. So AFAICS, we should always have a thread when the SafeFetch is called. 

Probably a fix to the https://bugs.openjdk.java.net/browse/JDK-8262903 could just move ThreadWXEnable under the `if`. But now after https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576is ThreadWXEnable allows optional W^X state change, like `MutexLocker` allows optional locking.

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

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

From shade at openjdk.java.net  Fri Mar 12 07:22:26 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 12 Mar 2021 07:22:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263467: Incorrect double-checked
 locking in sun.java2d.CRenderer [v2]
In-Reply-To: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>
References: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>
Message-ID: <kHqn5LKHE-Ik-aJJ4cFATDAn1oEW7q1lHUj38QfSE9o=.e1cc7adf-5943-4f08-9515-b89247b6dda8@github.com>

> SonarCloud reports multiple incorrect double-checked locking cases in `sun.java2d.CRenderer`. For example:
> 
>   Arc2D arcToShape;
> 
>   ...
>             if (arcToShape == null) {
>                 synchronized (this) {
>                     if (arcToShape == null) {
>                         arcToShape = new Arc2D.Float();
>                     }
>                 }
>             }
> 
> `Arc2D` contains fields that are not `final`. `arcToShape` is not `volatile`. This makes it an incorrect DCL.
> This code is used by Mac OS, do it would probably blow up some time later on M1.
> 
> This is the candidate fix that preserves the semantics. I am doing this fix blindly so far, without testing on real Mac OS. But maybe there is no need to do any of this, because the setter methods overwrite the contents of all these objects under their own sync. So, maybe we can just allocate those objects without DCL-backed caching and pass them in?

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

  Drop DCL and useless synchronization completely

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2948/files
  - new: https://git.openjdk.java.net/jdk/pull/2948/files/c81b9ea2..d912f559

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

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

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

From shade at openjdk.java.net  Fri Mar 12 07:22:26 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 12 Mar 2021 07:22:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263467: Incorrect double-checked
 locking in sun.java2d.CRenderer
In-Reply-To: <zmmHhWjVPatEQUEtSBMUPHHU85LwF230DL0DabQPP-o=.56152a15-9d69-4611-b5d9-5d8caccab91f@github.com>
References: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>
 <zmmHhWjVPatEQUEtSBMUPHHU85LwF230DL0DabQPP-o=.56152a15-9d69-4611-b5d9-5d8caccab91f@github.com>
Message-ID: <DUQzb763KFDsDGZp81gQYSSsRnF7dYfzX_sUNEb75LY=.8b8c680d-c245-49b5-b01c-6759cf1289eb@github.com>

On Fri, 12 Mar 2021 03:19:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> SonarCloud reports multiple incorrect double-checked locking cases in `sun.java2d.CRenderer`. For example:
>> 
>>   Arc2D arcToShape;
>> 
>>   ...
>>             if (arcToShape == null) {
>>                 synchronized (this) {
>>                     if (arcToShape == null) {
>>                         arcToShape = new Arc2D.Float();
>>                     }
>>                 }
>>             }
>> 
>> `Arc2D` contains fields that are not `final`. `arcToShape` is not `volatile`. This makes it an incorrect DCL.
>> This code is used by Mac OS, do it would probably blow up some time later on M1.
>> 
>> This is the candidate fix that preserves the semantics. I am doing this fix blindly so far, without testing on real Mac OS. But maybe there is no need to do any of this, because the setter methods overwrite the contents of all these objects under their own sync. So, maybe we can just allocate those objects without DCL-backed caching and pass them in?
>
> I guess "Incorrect double-checked" is a too strict description of this code, it just tried to eliminate the creation of one object and do not care about the content of that object, since it is immediately overridden. 
> 
> I think It will be more clear to just eliminate this DCL since overhead and code complexity seems too much to just cache five objects.
> 
> Probably it was important in past(jdk6 and below) when this renderer was used for onscreen rendering. Currently, it is used for printing(if actually used at all).

Ok, I removed the "DCL" from that code and used the objects directly. AFAICS, synchronization is redundant on those local objects. What would be a good test for this change?

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

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

From aghaisas at openjdk.java.net  Fri Mar 12 07:23:25 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 12 Mar 2021 07:23:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
 <O6wm8CU1omGiKP4dMhh5gkZoeMCdksaAd8aAWGbN4Q8=.0bc8e842-773f-449f-8ad6-0aabaef600e6@github.com>
Message-ID: <AVUdzVM5doUqkXlTgC9T1Gsi8UTJfS1aBcDhclZFPh0=.55541053-3f60-4693-b047-796f97a16167@github.com>

On Fri, 12 Mar 2021 01:01:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ajit Ghaisas 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 47 additional commits since the last revision:
>> 
>>  - Lanai PR#214 - 8263324 - avu
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#213 - 8263325 - avu
>>  - Lanai PR#212 - 8259825 - aghaisas
>>  - Lanai PR#211 - 8262882 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#210 - 8263159 - jdv
>>  - Lanai PR#209 - 8262936 - jdv
>>  - Lanai PR#208 - 8262928 - jdv
>>  - Lanai PR#207 - 8262750 - jdv
>>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/774f3477...369c3d21
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 148:
> 
>> 146:         rq.lock();
>> 147:         try {
>> 148:             // getMTLConfigInfo() creates and destroys temporary
> 
> Does it really create and destroy temporary surfaces/contexts?

No, it doesn't. I have updated JDK-8263363 to include this correction.

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

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

From david.holmes at oracle.com  Fri Mar 12 07:58:56 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Mar 2021 17:58:56 +1000
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v25]
In-Reply-To: <lPoCNtc83YmZudBHHRDi_pc4xqoTTIzA0b-TzxQXV9o=.1754abd9-5747-4528-a040-0abf5ff6af35@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
 <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>
 <lPoCNtc83YmZudBHHRDi_pc4xqoTTIzA0b-TzxQXV9o=.1754abd9-5747-4528-a040-0abf5ff6af35@github.com>
Message-ID: <59c46a13-91d9-bd60-70dd-ff8fde81c0c7@oracle.com>

On 12/03/2021 5:12 pm, Anton Kozlov wrote:
> On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    8262903: [macos_aarch64] Thread::current() called on detached thread
>>
>> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
>>
>>> 33: inline int SafeFetch32(int* adr, int errValue) {
>>> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>>> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));
>>
>> I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.
> 
> I'm not sure about expected behavior then. We may crash trying to execute the generated code, since we may have no WXExec. If we switch to WXExec, we would need to go back to a previous W^X state, but we don't know which one without the thread.

The NULL check is only part of it. In a signal handling context 
Thread::current() is not safe to call, you have to use 
Thread::current_or_null_safe().

> BTW, the test passes, probably that's why it didn't get attention. All non-trivial actions in the current implementation of `pd_hotspot_signal_handler` (hhttps://github.com/openjdk/jdk/pull/2200/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40R215-R324) assume non-NULL thread. So AFAICS, we should always have a thread when the SafeFetch is called.

Okay but you still need to use Thread::current_or_null_safe().

Cheers,
David

> Probably a fix to the https://bugs.openjdk.java.net/browse/JDK-8262903 could just move ThreadWXEnable under the `if`. But now after https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576is ThreadWXEnable allows optional W^X state change, like `MutexLocker` allows optional locking.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2200
> 

From kizune at openjdk.java.net  Fri Mar 12 08:35:40 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 12 Mar 2021 08:35:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
Message-ID: <S3TmBIhCjqn4tlEjjAPF3ct8DGwzILMqKqbTnT29PAo=.9fbac66e-8fdd-40ce-99e5-63b1aaf27fd2@github.com>

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 47 additional commits since the last revision:
> 
>  - Lanai PR#214 - 8263324 - avu
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/392a1086...369c3d21

Marked as reviewed by kizune (Reviewer).

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

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

From serb at openjdk.java.net  Fri Mar 12 08:39:21 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 08:39:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263482: Make access to the ICC color
 profiles data multithread-friendly
Message-ID: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>

FYI: probably is better/simpler to review it via webrev.

After migration to the lcms from the kcms the performance of some operations was regressed. One possible workaround was to split the operation into multiple threads. But unfortunately, we have too many bottlenecks which prevent using multithreading. This is the request to remove/minimize such bottlenecks(at least some of them), but it does not affect the single-threaded performance it should be handled separately.

The main code pattern optimized here is this:
    activate();
    byte[] theHeader = getData(cmmProfile, icSigHead);
    ---->  CMSManager.getModule().getTagData(p, tagSignature);
Notes about the code above:

1. Before the change "activate()" method checked that the "cmmProfile" field was not null. After that we usually used the "cmmProfile" as the parameter to some other method. This included two volatile reads, and also required to check when we need to call the "activate()" method before usage of the "cmmProfile" field.
Solution: "activate()" renamed to the "cmmProfile()" which became an accessor for the field, so we will get one volatile read and can easily monitor the usage of the field itself(it is used directly only in this method).

2. The synchronized static method "CMSManager.getModule()" reimplemented to have only one volatile read.

3. The usage of locking in the "getTagData()" is changed. Instead of the synchronized instance methods, we now use the mix of "ConcurrentHashMap" and StampedLock.

See some comments inline.

Some numbers(small numbers are better):

1. Performance of ((ICC_ProfileRGB) ICC_Profile.getInstance(ColorSpace.CS_sRGB)).getMatrix();

jdk 15.0.2
Benchmark                              Mode  Cnt    Score      Error  Units
CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   19,624 ?    0,059  us/op
CMMPerf.testGetMatrix                  avgt    5    0,154 ?    0,001  us/op

jdk - before the fix
Benchmark                              Mode  Cnt    Score      Error  Units
CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   12,935 ?    0,042  us/op
CMMPerf.testGetMatrix                  avgt    5    0,127 ?    0,007  us/op

jdk - after the fix
Benchmark                              Mode  Cnt    Score      Error  Units
CMMPerf.ThreadsMAX.testGetMatrix       avgt    5    0,561 ?    0,005  us/op
CMMPerf.testGetMatrix                  avgt    5    0,092 ?    0,001  us/op

2. Part of performance gain in jdk17 is from some other fixes, for example
    Performance of ICC_Profile.getInstance(ColorSpace.CS_sRGB); and ColorSpace.getInstance(ColorSpace.CS_sRGB);

jdk 15.0.2
Benchmark                              Mode  Cnt    Score      Error  Units
CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    2,299 ?    0,032  us/op
CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    2,210 ?    0,051  us/op
CMMPerf.testGetSRGBProfile             avgt    5    0,019 ?    0,001  us/op
CMMPerf.testGetSRGBSpace               avgt    5    0,018 ?    0,001  us/op

jdk - same before/ after the fix
Benchmark                              Mode  Cnt    Score      Error  Units
CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    0,005 ?    0,001  us/op
CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    0,005 ?    0,001  us/op
CMMPerf.testGetSRGBProfile             avgt    5    0,005 ?    0,001  us/op
CMMPerf.testGetSRGBSpace               avgt    5    0,005 ?    0,001  us/op

note "ThreadsMAX" is 32 threads.

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

Commit messages:
 - Update ICC_Profile.java
 - Merge branch 'master' into threads
 - Update LCMS.c
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/2957/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2957&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263482
  Stats: 212 lines in 5 files changed: 52 ins; 83 del; 77 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2957.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2957/head:pull/2957

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

From serb at openjdk.java.net  Fri Mar 12 08:39:22 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 12 Mar 2021 08:39:22 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263482: Make access to the ICC color
 profiles data multithread-friendly
In-Reply-To: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>
References: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>
Message-ID: <5WELH-SPWiqcaWzFO7-DGbEt4LimbHFe0HTxcMVgF7c=.83e6fd99-5da7-4124-9344-c0fb2ec3b51a@github.com>

On Fri, 12 Mar 2021 05:10:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> FYI: probably is better/simpler to review it via webrev.
> 
> After migration to the lcms from the kcms the performance of some operations was regressed. One possible workaround was to split the operation into multiple threads. But unfortunately, we have too many bottlenecks which prevent using multithreading. This is the request to remove/minimize such bottlenecks(at least some of them), but it does not affect the single-threaded performance it should be handled separately.
> 
> The main code pattern optimized here is this:
>     activate();
>     byte[] theHeader = getData(cmmProfile, icSigHead);
>     ---->  CMSManager.getModule().getTagData(p, tagSignature);
> Notes about the code above:
> 
> 1. Before the change "activate()" method checked that the "cmmProfile" field was not null. After that we usually used the "cmmProfile" as the parameter to some other method. This included two volatile reads, and also required to check when we need to call the "activate()" method before usage of the "cmmProfile" field.
> Solution: "activate()" renamed to the "cmmProfile()" which became an accessor for the field, so we will get one volatile read and can easily monitor the usage of the field itself(it is used directly only in this method).
> 
> 2. The synchronized static method "CMSManager.getModule()" reimplemented to have only one volatile read.
> 
> 3. The usage of locking in the "getTagData()" is changed. Instead of the synchronized instance methods, we now use the mix of "ConcurrentHashMap" and StampedLock.
> 
> See some comments inline.
> 
> Some numbers(small numbers are better):
> 
> 1. Performance of ((ICC_ProfileRGB) ICC_Profile.getInstance(ColorSpace.CS_sRGB)).getMatrix();
> 
> jdk 15.0.2
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   19,624 ?    0,059  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,154 ?    0,001  us/op
> 
> jdk - before the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   12,935 ?    0,042  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,127 ?    0,007  us/op
> 
> jdk - after the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5    0,561 ?    0,005  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,092 ?    0,001  us/op
> 
> 2. Part of performance gain in jdk17 is from some other fixes, for example
>     Performance of ICC_Profile.getInstance(ColorSpace.CS_sRGB); and ColorSpace.getInstance(ColorSpace.CS_sRGB);
> 
> jdk 15.0.2
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    2,299 ?    0,032  us/op
> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    2,210 ?    0,051  us/op
> CMMPerf.testGetSRGBProfile             avgt    5    0,019 ?    0,001  us/op
> CMMPerf.testGetSRGBSpace               avgt    5    0,018 ?    0,001  us/op
> 
> jdk - same before/ after the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    0,005 ?    0,001  us/op
> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    0,005 ?    0,001  us/op
> CMMPerf.testGetSRGBProfile             avgt    5    0,005 ?    0,001  us/op
> CMMPerf.testGetSRGBSpace               avgt    5    0,005 ?    0,001  us/op
> 
> note "ThreadsMAX" is 32 threads.

src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSProfile.java line 70:

> 68:         } finally {
> 69:             lock.unlockRead(stamp);
> 70:         }

The comments about the change in this class and the changes in the "getTag()" method.
1. I have removed the TagData and TagCache classes and move the tag cache to the profile class directly.
2. I have moved synchronization logic from the LCMS.java to this class, so now we can use more "granular" synchronizations.

The logic behind this change:
1. The StampedLock guards the access to the native lcms code, so when we change the tags via "LCMS.setTagDataNative" nobody will call "LCMS.getTagNative" and "LCMS.getProfileDataNative". I tried the "ReentrantReadWriteLock", but it is a little bit slower.
2. The cache itself is maintained by the ConcurrentHashMap, and the usage of "byte[] t = tags.get(sig);" w/o synchronization is a key for the performance.

Note that it is possible to use "tags.computeIfAbsent" instead of "tags.get(sig)" and take care of "native access" synchronization in the "LCMS.getTagNative", but unfortuntly for some workload the "get()" is x10 times faster than computeIfAbsent() if the key is already exists in the map(common situation for the cache).

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1103:

> 1101:     public byte[] getData(int tagSignature) {
> 1102:         byte[] t = getData(cmmProfile(), tagSignature);
> 1103:         return t != null ? t.clone() : null;

I have moved the clone operation to the public "ICC_Profile.getData(int tagSignature)" method, so we do not clone it again again and again when we use this data internally.

src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMS.java line 84:

> 82:     @Override
> 83:     public synchronized void setTagData(Profile p, int tagSignature, byte[] data) {
> 84:         getLcmsProfile(p).setTag(tagSignature, data);

Note that this method is synchronized, I think it is not needed to be, because a long time ago(before the LCMSProfile class was implemented ) all method in this class was synchronized to guard information about tags. But later we changed all such synchronization methods to the per-profile locks. And only this method remains synchronized.

But I leave it as is for now, since it might affect transforms which I am not touching in this fix. WIll remove that later.

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

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

From jdv at openjdk.java.net  Fri Mar 12 10:01:47 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 12 Mar 2021 10:01:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
Message-ID: <ggSUbZ4hexsolD3PSx4AbIlGInWpyoLNMD6VOcxwHyU=.711d4c1b-3db1-42f0-95e5-4a8eb807052b@github.com>

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 47 additional commits since the last revision:
> 
>  - Lanai PR#214 - 8263324 - avu
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/46a8379b...369c3d21

Marked as reviewed by jdv (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Fri Mar 12 10:14:36 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 10:14:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
Message-ID: <hsypvCY76b6SfuEyM-phM4Ns1ibmBOIJsMPBpd-V3Wg=.4f4d2824-b61b-4528-90bb-6f8056793828@github.com>

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 47 additional commits since the last revision:
> 
>  - Lanai PR#214 - 8263324 - avu
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/b163fb99...369c3d21

src/java.desktop/macosx/classes/sun/awt/CGraphicsConfig.java line 82:

> 80:      * Creates a new SurfaceData that will be associated with the given
> 81:      * CGLLayer.
> 82:      */

I guess we need to specify CGLLayer/MTLLayer as now we are implementing this method in both pipeline.

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

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

From psadhukhan at openjdk.java.net  Fri Mar 12 10:17:40 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 10:17:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
Message-ID: <mnPnh_T3yaKiblJjzxaCpMNjLIuwfG5nVdJngaIZrqA=.db74b8e5-8072-428b-ba41-08590007cfd4@github.com>

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 47 additional commits since the last revision:
> 
>  - Lanai PR#214 - 8263324 - avu
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/d4addb43...369c3d21

Marked as reviewed by psadhukhan (Reviewer).

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

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

From aghaisas at openjdk.java.net  Fri Mar 12 10:57:23 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 12 Mar 2021 10:57:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <hsypvCY76b6SfuEyM-phM4Ns1ibmBOIJsMPBpd-V3Wg=.4f4d2824-b61b-4528-90bb-6f8056793828@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
 <hsypvCY76b6SfuEyM-phM4Ns1ibmBOIJsMPBpd-V3Wg=.4f4d2824-b61b-4528-90bb-6f8056793828@github.com>
Message-ID: <0I8-1HTnTUMOkSlYrUoNgCEzQttHPHIoqVy0Jg34QGc=.bf4e9c8a-a6b6-4857-915b-0a7d4615a300@github.com>

On Fri, 12 Mar 2021 10:11:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Ajit Ghaisas 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 47 additional commits since the last revision:
>> 
>>  - Lanai PR#214 - 8263324 - avu
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#213 - 8263325 - avu
>>  - Lanai PR#212 - 8259825 - aghaisas
>>  - Lanai PR#211 - 8262882 - aghaisas
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#210 - 8263159 - jdv
>>  - Lanai PR#209 - 8262936 - jdv
>>  - Lanai PR#208 - 8262928 - jdv
>>  - Lanai PR#207 - 8262750 - jdv
>>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/f5d78efb...369c3d21
>
> src/java.desktop/macosx/classes/sun/awt/CGraphicsConfig.java line 82:
> 
>> 80:      * Creates a new SurfaceData that will be associated with the given
>> 81:      * CGLLayer.
>> 82:      */
> 
> I guess we need to specify CGLLayer/MTLLayer as now we are implementing this method in both pipeline.

I have updated JDK-8263363 to include this.

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

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

From aivanov at openjdk.java.net  Fri Mar 12 11:32:10 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 12 Mar 2021 11:32:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <1XWnbAUoXYd0shleNnct4uky2ZboVmUSvPJ5AXXsheM=.5bdbc41e-ab5b-4037-9872-7f4261d5a462@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <425OYVrQ8UldCi_4u-C5Q1RiYJJr5lrCT4mOmO-CDG4=.53915594-664a-4971-b04d-5097cec69028@github.com>
 <1XWnbAUoXYd0shleNnct4uky2ZboVmUSvPJ5AXXsheM=.5bdbc41e-ab5b-4037-9872-7f4261d5a462@github.com>
Message-ID: <WaVas_hjnSfm6EUH-7V9VW2Ox0ma7VSEK1len0uBRcM=.360e27e9-3e69-40c3-85d6-42daebab9f5b@github.com>

On Fri, 12 Mar 2021 04:55:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Is this only about addition/removal? What about printer name change?

You cannot change the name of a remote printer.

Opening *Printer Properties* dialog from the printer context menu on the local host and editing its name changes the name of the printer on the remote host which shares it. Windows warns, ?This is a shared printer. If you rename a shared printer, existing connections to this printer from other computers will break and will have to be created again.?

Nothing has been updated on the local system after renaming the printer. As the warning said, the printer does not work any more because it refers to a printer that does not exist.

To fix this, one has to add a new remote printer which refers to the new name of the printer on the remote host.

> Shouldn't we get notified in that case as trying to print on printer with old name will not find the printer!!

I'm afraid there's nothing Java can do to mitigate renaming the printer.

> If yes, in that regard I guess `REG_NOTIFY_CHANGE_LAST_SET` is the one to go for as it states
> _"Notify the caller of changes to a value of the key. This can include adding or deleting a value, or changing an existing value. "_

Since no values are created, removed, or changed when a remote printer is added or removed under `Connections` key, adding `REG_NOTIFY_CHANGE_LAST_SET` to `dwNotifyFilter` is not required. There are some values stored in the printer key but Java does not use them directly; if any value is changed there, getting notifications about such an event only creates noise.

So, as far as Java is concerned, getting notifications about new keys being created or removed under `Connections` is enough. This is what `REG_NOTIFY_CHANGE_NAME` filter does.

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

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

From psadhukhan at openjdk.java.net  Fri Mar 12 11:41:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 11:41:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <WaVas_hjnSfm6EUH-7V9VW2Ox0ma7VSEK1len0uBRcM=.360e27e9-3e69-40c3-85d6-42daebab9f5b@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <425OYVrQ8UldCi_4u-C5Q1RiYJJr5lrCT4mOmO-CDG4=.53915594-664a-4971-b04d-5097cec69028@github.com>
 <1XWnbAUoXYd0shleNnct4uky2ZboVmUSvPJ5AXXsheM=.5bdbc41e-ab5b-4037-9872-7f4261d5a462@github.com>
 <WaVas_hjnSfm6EUH-7V9VW2Ox0ma7VSEK1len0uBRcM=.360e27e9-3e69-40c3-85d6-42daebab9f5b@github.com>
Message-ID: <0aOvO_Sq5WlyJ9TyMx0srApvcxP5hZ9mkmXY2-wsx9I=.54dca08e-e4a9-41ab-af94-a454d988ffe8@github.com>

On Fri, 12 Mar 2021 11:29:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Is this only about addition/removal? What about printer name change? Shouldn't we get notified in that case as trying to print on printer with old name will not find the printer!!
>> If yes, in that regard I guess REG_NOTIFY_CHANGE_LAST_SET is the one to go for as it states
>> `"Notify the caller of changes to a value of the key. This can include adding or deleting a value, or changing an existing value. "`
>
>> Is this only about addition/removal? What about printer name change?
> 
> You cannot change the name of a remote printer.
> 
> Opening *Printer Properties* dialog from the printer context menu on the local host and editing its name changes the name of the printer on the remote host which shares it. Windows warns, ?This is a shared printer. If you rename a shared printer, existing connections to this printer from other computers will break and will have to be created again.?
> 
> Nothing has been updated on the local system after renaming the printer. As the warning said, the printer does not work any more because it refers to a printer that does not exist.
> 
> To fix this, one has to add a new remote printer which refers to the new name of the printer on the remote host.
> 
>> Shouldn't we get notified in that case as trying to print on printer with old name will not find the printer!!
> 
> I'm afraid there's nothing Java can do to mitigate renaming the printer.
> 
>> If yes, in that regard I guess `REG_NOTIFY_CHANGE_LAST_SET` is the one to go for as it states
>> _"Notify the caller of changes to a value of the key. This can include adding or deleting a value, or changing an existing value. "_
> 
> Since no values are created, removed, or changed when a remote printer is added or removed under `Connections` key, adding `REG_NOTIFY_CHANGE_LAST_SET` to `dwNotifyFilter` is not required. There are some values stored in the printer key but Java does not use them directly; if any value is changed there, getting notifications about such an event only creates noise.
> 
> So, as far as Java is concerned, getting notifications about new keys being created or removed under `Connections` is enough. This is what `REG_NOTIFY_CHANGE_NAME` filter does.

I can understand that as a user, you cannot /shouldn't change the name of a remote network printer but a network admin can change the name, so shouldn't we get notification on that name change when this method gets called after the name change? or would it be notified as a new printer in that case? Then what will happen to the old stale printer in the registry?

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

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

From akozlov at openjdk.java.net  Fri Mar 12 12:17:39 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 12:17:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v26]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <ioUfr36PoGR8ir-TiecioR9y0BI2GfmVq_aWST1b5Uc=.f69452f0-4289-4a29-9857-1b833070b80f@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision:

 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/f6fb01b2..29991c92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=24-25

  Stats: 83 lines in 53 files changed: 41 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From aivanov at openjdk.java.net  Fri Mar 12 12:34:05 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 12 Mar 2021 12:34:05 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <0aOvO_Sq5WlyJ9TyMx0srApvcxP5hZ9mkmXY2-wsx9I=.54dca08e-e4a9-41ab-af94-a454d988ffe8@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <425OYVrQ8UldCi_4u-C5Q1RiYJJr5lrCT4mOmO-CDG4=.53915594-664a-4971-b04d-5097cec69028@github.com>
 <1XWnbAUoXYd0shleNnct4uky2ZboVmUSvPJ5AXXsheM=.5bdbc41e-ab5b-4037-9872-7f4261d5a462@github.com>
 <WaVas_hjnSfm6EUH-7V9VW2Ox0ma7VSEK1len0uBRcM=.360e27e9-3e69-40c3-85d6-42daebab9f5b@github.com>
 <0aOvO_Sq5WlyJ9TyMx0srApvcxP5hZ9mkmXY2-wsx9I=.54dca08e-e4a9-41ab-af94-a454d988ffe8@github.com>
Message-ID: <0ZsLW_DEUjTIkgIM6REXgeBd4c6LV-LNu08h384a2xc=.d2dcea8a-70e9-4819-9053-a03e16258df7@github.com>

On Fri, 12 Mar 2021 11:38:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Is this only about addition/removal? What about printer name change?
>> 
>> You cannot change the name of a remote printer.
>> 
>> Opening *Printer Properties* dialog from the printer context menu on the local host and editing its name changes the name of the printer on the remote host which shares it. Windows warns, ?This is a shared printer. If you rename a shared printer, existing connections to this printer from other computers will break and will have to be created again.?
>> 
>> Nothing has been updated on the local system after renaming the printer. As the warning said, the printer does not work any more because it refers to a printer that does not exist.
>> 
>> To fix this, one has to add a new remote printer which refers to the new name of the printer on the remote host.
>> 
>>> Shouldn't we get notified in that case as trying to print on printer with old name will not find the printer!!
>> 
>> I'm afraid there's nothing Java can do to mitigate renaming the printer.
>> 
>>> If yes, in that regard I guess `REG_NOTIFY_CHANGE_LAST_SET` is the one to go for as it states
>>> _"Notify the caller of changes to a value of the key. This can include adding or deleting a value, or changing an existing value. "_
>> 
>> Since no values are created, removed, or changed when a remote printer is added or removed under `Connections` key, adding `REG_NOTIFY_CHANGE_LAST_SET` to `dwNotifyFilter` is not required. There are some values stored in the printer key but Java does not use them directly; if any value is changed there, getting notifications about such an event only creates noise.
>> 
>> So, as far as Java is concerned, getting notifications about new keys being created or removed under `Connections` is enough. This is what `REG_NOTIFY_CHANGE_NAME` filter does.
>
> I can understand that as a user, you cannot /shouldn't change the name of a remote network printer but a network admin can change the name, so shouldn't we get notification on that name change when this method gets called after the name change? or would it be notified as a new printer in that case? Then what will happen to the old stale printer in the registry?

You can't. Try it yourself. The printer connection is per-user, after all it's stored under HKCU.

Windows displays the name of remote printers as ?Generic / Text Only on 192.168.1.18?: _the name of the printer_ and _the remote host_.

If you open the *Printer Properties* dialog of a remote printer and edit its name, you change the name of the printer on the remote host which shares it. It changes *absolutely nothing* on the local system.

> shouldn't we get notification on that name change when this method gets called after the name change?

Yes, we should. But we cannot.

For Windows, nothing has changed on the local system, it's the remote system that has been changed.

> or would it be notified as a new printer in that case?

No, it wouldn't _because nothing has changed on the local system_.

> Then what will happen to the old stale printer in the registry?

Nothing, again. It just stays there but Windows reports an error if you try to open its Printer Properties, Windows reports an error if you try to print to it. I tried printing with Java and Notepad: the behaviour is the same. The difference is that Notepad displays the error message whereas Java throws an exception (it depends on the Java app, I guess).

The behaviour aligns to the one seen when the printer is unreachable because of, let's say, network issues.

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

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

From psadhukhan at openjdk.java.net  Fri Mar 12 12:42:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 12:42:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
Message-ID: <lv15MEUL7W5kM37ceHgrkncgUR7wcnNgcx7v3mME5dc=.a2a96669-78c0-47fe-97fe-7a3936dbfb01@github.com>

On Wed, 10 Mar 2021 15:38:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented polling for remote printers.
> That bug description also mentions watching the registry for changes and links to the article which describes the method yet it does so in terms of WMI. Using WMI is not necessary to watch for the registry updates.
> 
> It is possible to replace polling mechanism with registry change notifications. If the registry at `HKCU\Printers\Connections` is updated, refresh the list of print services.
> 
> It works perfectly well in my own testing with sharing a Generic / Text Only printer from another laptop. The notification comes as soon as the printer is installed, it results in a new key created under `Connections`. If a remote printer is removed, the notification is also triggered as the key corresponding to that printer is removed from the registry.
> 
> I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`.

Marked as reviewed by psadhukhan (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Fri Mar 12 12:42:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 12 Mar 2021 12:42:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <0ZsLW_DEUjTIkgIM6REXgeBd4c6LV-LNu08h384a2xc=.d2dcea8a-70e9-4819-9053-a03e16258df7@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <425OYVrQ8UldCi_4u-C5Q1RiYJJr5lrCT4mOmO-CDG4=.53915594-664a-4971-b04d-5097cec69028@github.com>
 <1XWnbAUoXYd0shleNnct4uky2ZboVmUSvPJ5AXXsheM=.5bdbc41e-ab5b-4037-9872-7f4261d5a462@github.com>
 <WaVas_hjnSfm6EUH-7V9VW2Ox0ma7VSEK1len0uBRcM=.360e27e9-3e69-40c3-85d6-42daebab9f5b@github.com>
 <0aOvO_Sq5WlyJ9TyMx0srApvcxP5hZ9mkmXY2-wsx9I=.54dca08e-e4a9-41ab-af94-a454d988ffe8@github.com>
 <0ZsLW_DEUjTIkgIM6REXgeBd4c6LV-LNu08h384a2xc=.d2dcea8a-70e9-4819-9053-a03e16258df7@github.com>
Message-ID: <-X1FoTkGPAtEMTzCEgm_d8MQ4aP717IvmFne__v-fNA=.386ee0fa-80fb-4f0f-a8e6-aae50f1fcd28@github.com>

On Fri, 12 Mar 2021 12:30:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I can understand that as a user, you cannot /shouldn't change the name of a remote network printer but a network admin can change the name, so shouldn't we get notification on that name change when this method gets called after the name change? or would it be notified as a new printer in that case? Then what will happen to the old stale printer in the registry?
>
> You can't. Try it yourself. The printer connection is per-user, after all it's stored under HKCU.
> 
> Windows displays the name of remote printers as ?Generic / Text Only on 192.168.1.18?: _the name of the printer_ and _the remote host_.
> 
> If you open the *Printer Properties* dialog of a remote printer and edit its name, you change the name of the printer on the remote host which shares it. It changes *absolutely nothing* on the local system.
> 
>> shouldn't we get notification on that name change when this method gets called after the name change?
> 
> Yes, we should. But we cannot.
> 
> For Windows, nothing has changed on the local system, it's the remote system that has been changed.
> 
>> or would it be notified as a new printer in that case?
> 
> No, it wouldn't _because nothing has changed on the local system_.
> 
>> Then what will happen to the old stale printer in the registry?
> 
> Nothing, again. It just stays there but Windows reports an error if you try to open its Printer Properties, Windows reports an error if you try to print to it. I tried printing with Java and Notepad: the behaviour is the same. The difference is that Notepad displays the error message whereas Java throws an exception (it depends on the Java app, I guess).
> 
> The behaviour aligns to the one seen when the printer is unreachable because of, let's say, network issues.

OK.

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

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

From vkempik at openjdk.java.net  Fri Mar 12 13:38:17 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Mar 2021 13:38:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v9]
In-Reply-To: <Ei8n5Xqt_Usrtyz-M4AudO6fuOV30FTSG6BCpNXUa2w=.fe6928be-256e-4448-b094-1f7c869e4b26@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>
 <Ei8n5Xqt_Usrtyz-M4AudO6fuOV30FTSG6BCpNXUa2w=.fe6928be-256e-4448-b094-1f7c869e4b26@github.com>
Message-ID: <YzgtINrzUk1D0dPpOvX2IZyIMhIMC4HqY3FoKtGO6TU=.377dfcb8-98d0-4fc5-ab40-11974e8266d0@github.com>

On Tue, 2 Mar 2021 08:12:10 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround
>> @gerard-ziemski, 8020753 was originally your fix, do you know if it still needed on intel-mac ?
>
> The x86_bsd still carries the workaround https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745. It's worth having macos ports to be aligned by features. I would propose to have this workaround for now, and decide on it later for macos/x86 and macos/aarch64 at once. Sorry for chiming in so late.

Hello Anton.
Please keep JDK-8020753 away from this port, as JDK-8020753 was very intel-specific workaround and macos11.0 on aarch64 doesn't show any signs of original bug.

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

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

From akozlov at openjdk.java.net  Fri Mar 12 14:10:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 14:10:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v25]
In-Reply-To: <gKoH7dS4tYmoRme7Wzbg1mH0ygHFKlaTQgS_JiIE_8A=.96b62223-ef50-43f5-9db1-d150e449e1b9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
 <gKoH7dS4tYmoRme7Wzbg1mH0ygHFKlaTQgS_JiIE_8A=.96b62223-ef50-43f5-9db1-d150e449e1b9@github.com>
Message-ID: <ZSTPk6hVzz7glzH2jZYiRfbEJ0IYKpjWJFpPJ1evnJg=.09ce1d0a-a175-40e7-9005-c1b701f73154@github.com>

On Thu, 11 Mar 2021 20:28:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8262903: [macos_aarch64] Thread::current() called on detached thread
>
> Marked as reviewed by stefank (Reviewer).

> you still need to use Thread::current_or_null_safe() [for SafeFetch].

OK :) I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/fd4812e585e0528010a8863df50956a3b64a6744

@dcubed-ojdk, I also updated copyrights, this concludes fixes for the review https://github.com/openjdk/jdk/pull/2200#pullrequestreview-581784107.

@theRealAph, could you elaborate on what is need to be done for https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066.

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

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

From aph at openjdk.java.net  Fri Mar 12 16:35:23 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 12 Mar 2021 16:35:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v24]
In-Reply-To: <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
Message-ID: <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>

On Tue, 9 Mar 2021 16:12:36 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
> 
>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>  - workaround JDK-8262895 by disabling subtest
>  - Fix typo
>  - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
>  - JDK-8259937: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Fix after JDK-8259539, partially revert preconditions
>  - JDK-8260471: bsd_aarch64 part
>  - JDK-8259539: bsd_aarch64 part
>  - JDK-8257828: bsd_aarch64 part
>  - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834

> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).

I think that what you've got now is fine.

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

Marked as reviewed by aph (Reviewer).

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

From herrick at openjdk.java.net  Fri Mar 12 16:13:36 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 12 Mar 2021 16:13:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to Applet
 API deprecations
Message-ID: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>

implementation of
JDK-8256145: JEP 398: Deprecate the Applet API for Removal

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

Commit messages:
 - 8189198: Add "forRemoval = true" to Applet API deprecations

Changes: https://git.openjdk.java.net/jdk/pull/2920/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2920&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8189198
  Stats: 74 lines in 22 files changed: 14 ins; 0 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2920/head:pull/2920

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

From aph at openjdk.java.net  Fri Mar 12 16:35:24 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 12 Mar 2021 16:35:24 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v21]
In-Reply-To: <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
 <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
 <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>
Message-ID: <SXXcMmMTXbltmXqeaDgF6g8EJvECwqtlNokXpNJ0CNI=.f358e952-3186-4503-a632-834ec4343c6d@github.com>

On Tue, 9 Mar 2021 18:01:11 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:
>> 
>>> 60: 
>>> 61: #if defined(__APPLE__) || defined(_WIN64)
>>> 62: #define R18_RESERVED
>> 
>> #define R18_RESERVED true```
>
> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?

Robustness, clarity, maintainability, convention. Why not?

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

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

From akozlov at openjdk.java.net  Fri Mar 12 16:44:38 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 16:44:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v27]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Fix most of issues in java/foreign/ tests
  
  Failures related to va_args are tracked in JDK-8263512.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/29991c92..5bfe0f08

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=26
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=25-26

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

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

From iris at openjdk.java.net  Fri Mar 12 18:20:06 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 12 Mar 2021 18:20:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <ZSNT5qc_BugwWIZl4x2ueqQObQFJgUQ6jzi5TZTrPhg=.57cc693b-41f8-43f2-92fb-f7c9d6b4d493@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Marked as reviewed by iris (Reviewer).

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

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

From serb at openjdk.java.net  Sat Mar 13 00:21:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 13 Mar 2021 00:21:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
Message-ID: <82CenQod4D7T0Wz5Uat6u-RfFLW01xVOV69zkTpIca0=.aaf34fca-2af3-4387-988d-048eb87af868@github.com>

On Wed, 10 Mar 2021 15:38:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented polling for remote printers.
> That bug description also mentions watching the registry for changes and links to the article which describes the method yet it does so in terms of WMI. Using WMI is not necessary to watch for the registry updates.
> 
> It is possible to replace polling mechanism with registry change notifications. If the registry at `HKCU\Printers\Connections` is updated, refresh the list of print services.
> 
> It works perfectly well in my own testing with sharing a Generic / Text Only printer from another laptop. The notification comes as soon as the printer is installed, it results in a new key created under `Connections`. If a remote printer is removed, the notification is also triggered as the key corresponding to that printer is removed from the registry.
> 
> I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`.

@aivanov-jdk can you please check what that old comment was about:

https://bugs.openjdk.java.net/browse/JDK-8153732?focusedCommentId=14188974&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14188974

Any idea why RegistryValueChange was rejected as a solution?

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

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

From prr at openjdk.java.net  Sat Mar 13 00:21:19 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 13 Mar 2021 00:21:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux
Message-ID: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>

>From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.

I ended up having to go this way because its is the least unsatisfactory solution.
I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
because too many systems have to old a version of harfbuzz.

This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10

There are couple of incidental fixes in here too
- "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
- harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
- I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502

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

Commit messages:
 - 8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Changes: https://git.openjdk.java.net/jdk/pull/2982/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2982&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255790
  Stats: 96 lines in 2 files changed: 7 ins; 57 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2982.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2982/head:pull/2982

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

From serb at openjdk.java.net  Sat Mar 13 00:37:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 13 Mar 2021 00:37:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux
In-Reply-To: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
Message-ID: <biJbAWHnKKS6bYO9vR5-cHEqzTOSKyyiZhPq2vLVFBQ=.dccc81c9-c986-400e-8beb-51d7fa096764@github.com>

On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race <prr at openjdk.org> wrote:

> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
> 
> I ended up having to go this way because its is the least unsatisfactory solution.
> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
> because too many systems have to old a version of harfbuzz.
> 
> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
> 
> There are couple of incidental fixes in here too
> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502

Marked as reviewed by serb (Reviewer).

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

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

From almatvee at openjdk.java.net  Sat Mar 13 00:46:07 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 13 Mar 2021 00:46:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Marked as reviewed by almatvee (Committer).

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

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

From dholmes at openjdk.java.net  Sat Mar 13 05:52:22 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 13 Mar 2021 05:52:22 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v27]
In-Reply-To: <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>
Message-ID: <FB2pev3OL8y-AYtFw1i8n3Np5ny9bYb8wdduqVtiXhA=.84f450cc-6891-4a0b-a84d-1abb8a2eaf00@github.com>

On Fri, 12 Mar 2021 16:44:38 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix most of issues in java/foreign/ tests
>   
>   Failures related to va_args are tracked in JDK-8263512.

src/hotspot/share/runtime/safefetch.inline.hpp line 35:

> 33: inline int SafeFetch32(int* adr, int errValue) {
> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
> 35:   Thread* thread = Thread::current_or_null_safe();

Sorry but this should be MACOS_AARCH64 only. All three lines need to be ifdef'd if you are going to include the assertion.

Thanks,
David

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

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

From aivanov at openjdk.java.net  Sat Mar 13 12:02:06 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 13 Mar 2021 12:02:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <82CenQod4D7T0Wz5Uat6u-RfFLW01xVOV69zkTpIca0=.aaf34fca-2af3-4387-988d-048eb87af868@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
 <82CenQod4D7T0Wz5Uat6u-RfFLW01xVOV69zkTpIca0=.aaf34fca-2af3-4387-988d-048eb87af868@github.com>
Message-ID: <oJOos4ajVZ3sIpLB56IdWoi5UXJ5FzUOBi_Z76CMG3U=.e9bf86cc-ec80-4626-abf8-34596ff24744@github.com>

On Sat, 13 Mar 2021 00:18:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Any idea why RegistryValueChange was rejected as a solution?

I've no idea. I read that comment, it's exactly the comment that was in the code above `RemotePrinterChangeListener` class in `PrintServiceLookupProvider.java`.

> RegistryValueChange cannot be used in combination with WMI to get registry value change notification because of an error that may be generated because the scope of the query would be too big to handle(at times).

It's very vague. I don't know what it really means. Neither do I know if a prototype was even tried.

If fact, this comment cites portions of the article [How to listen for Printer Connections?](https://docs.microsoft.com/en-gb/archive/blogs/hmahrt/how-to-listen-for-printer-connections). The link to this article is in the description of [JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732).

The article discusses the subject with WMI and WQL. This is what it says:

> There is no equivalent to `FindFirstPrinterChangeNotification`, which listens for new/changed Printer Connections ? and a polling mechanism was not an option. However, there is another way, using WMI.

Note: _polling mechanism was not an option_. Yet it is what was implemented in Java.

Then the articles describes the steps needed to monitor for printer changes.

Close to the end, there's the quoted sentence:

> Unfortunately, we cannot use the `RegistryValueChangeEvent` (because the scope of the query would be too big (we?d receive an error message), so we can only know **when** something changed below the `Printers\Connections` key, but not **what**. This is why we have to rely on **`EnumPrinters`**.

This statement is a bit confusing. It says they cannot use `RegistryValueChangeEvent` (it's not a Windows API function, it's another WMI class) but the WQL query above _uses it_.

I interpret the following statement this way: Registry notifications do not provide information on **what** changed under `Printers\Connections`, only that a change occurred. So `EnumPrinters` is used to enumerate the remote printers and update the stored list of printers after the change to the registry occurs.

I used this article as the inspiration and the implementation I'm proposing in this PR is purely based on this article. Yet I'm using Windows API function [RegNotifyChangeKeyValue](https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regnotifychangekeyvalue) to watch for registry updates and to get notified as soon as a change under `HKCU\Printers\Connections` occurs. Then the list of printers is updated by the `refreshServices` upcall into Java which refreshes both _local_ and _remote_ printers.

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

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

From serb at openjdk.java.net  Sun Mar 14 08:41:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 14 Mar 2021 08:41:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
Message-ID: <DA_WMRWlQA539Zya_fgdQi6a4c3vEcR3vApDfVcN97w=.99d8e5ae-57a9-48cc-af26-e4ae41967c16@github.com>

On Wed, 10 Mar 2021 15:38:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented polling for remote printers.
> That bug description also mentions watching the registry for changes and links to the article which describes the method yet it does so in terms of WMI. Using WMI is not necessary to watch for the registry updates.
> 
> It is possible to replace polling mechanism with registry change notifications. If the registry at `HKCU\Printers\Connections` is updated, refresh the list of print services.
> 
> It works perfectly well in my own testing with sharing a Generic / Text Only printer from another laptop. The notification comes as soon as the printer is installed, it results in a new key created under `Connections`. If a remote printer is removed, the notification is also triggered as the key corresponding to that printer is removed from the registry.
> 
> I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`.

Marked as reviewed by serb (Reviewer).

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

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

From alanb at openjdk.java.net  Sun Mar 14 12:09:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 12:09:05 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
Message-ID: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>

On Sat, 13 Mar 2021 00:43:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Marked as reviewed by almatvee (Committer).

Have you looked at narrowing the use of the SuppressWarnings to local variable declarations to avoid adding it to some of these methods?

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:09:21 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:09:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream
In-Reply-To: <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
Message-ID: <9WzDHjb3E5Afwj-g73SsX2P2rSbsNk0HCflWjpi0Or4=.55abfbfe-9e91-445c-ad38-7afb169c3365@github.com>

On Sun, 14 Mar 2021 07:51:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 57:
> 
>> 55:             // validate the header
>> 56:             byte[] magic = new byte[4];
>> 57:             in.read(magic);
> 
> While you are there, this can be changed to magic = in.readNBytes(4) and throw IOException if magic.length != 4.

Done.

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

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

From alanb at openjdk.java.net  Sun Mar 14 17:09:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 17:09:20 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>

On Sat, 13 Mar 2021 22:29:23 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 57:

> 55:             // validate the header
> 56:             byte[] magic = new byte[4];
> 57:             in.read(magic);

While you are there, this can be changed to magic = in.readNBytes(4) and throw IOException if magic.length != 4.

src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 58:

> 56:             byte[] magic = in.readNBytes(4);
> 57:             if (magic.length != 4) {
> 58:                 throw new IOException("Header expected to be of length 4, but was " + magic.length);

Thanks for the update. If magic != 4 then it means the file is not a JMOD file or that it has been truncated.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:09:20 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:09:20 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream
Message-ID: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>

In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.

Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

Commit messages:
 - Use InputStream.readNBytes()
 - Drop unnecessary BufferedInputStream-wrapping where possible

Changes: https://git.openjdk.java.net/jdk/pull/2992/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263560
  Stats: 14 lines in 3 files changed: 2 ins; 7 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2992/head:pull/2992

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:39:25 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:39:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v2]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <7MZ3DNHaLzsGrqQcbUo2l8Uj5hzlRMToZXF9_NoIAB0=.5fedbf9f-bf5d-4712-952f-82a02283d1e4@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Revert usage of InputStream.readNBytes()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/4c608737..12505d05

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:39:26 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:39:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v2]
In-Reply-To: <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
Message-ID: <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>

On Sun, 14 Mar 2021 11:16:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert usage of InputStream.readNBytes()
>
> src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 58:
> 
>> 56:             byte[] magic = in.readNBytes(4);
>> 57:             if (magic.length != 4) {
>> 58:                 throw new IOException("Header expected to be of length 4, but was " + magic.length);
> 
> Thanks for the update. If magic != 4 then it means the file is not a JMOD file or that it has been truncated.

It turned out, that with this latest update some of tier2_tools tests are failing, e.g. `JLinkNegativeTest`:
test JLinkNegativeTest.testMalformedJmod(): failure
java.lang.AssertionError: Output does not fit regexp: Error: java.io.IOException: Invalid JMOD file
	at tests.Result.assertFailure(Result.java:70)
	at JLinkNegativeTest.testMalformedJmod(JLinkNegativeTest.java:201)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
	at org.testng.TestRunner.privateRun(TestRunner.java:773)
	at org.testng.TestRunner.run(TestRunner.java:623)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
	at org.testng.TestNG.run(TestNG.java:1018)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)
...
java.lang.module.FindException: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:253)
	at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190)
	at java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154)
	at java.base/java.lang.module.Resolver.findWithBeforeFinder(Resolver.java:842)
	at java.base/java.lang.module.Resolver.resolve(Resolver.java:119)
	at java.base/java.lang.module.Configuration.resolve(Configuration.java:421)
	at java.base/java.lang.module.Configuration.resolve(Configuration.java:255)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.limitFinder(JlinkTask.java:545)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:466)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267)
	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
	at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:65)
	at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
	at tests.Helper.generateDefaultImage(Helper.java:257)
	at tests.Helper.generateDefaultImage(Helper.java:244)
	at JLinkNegativeTest.testSectionsAreFiles(JLinkNegativeTest.java:307)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
	at org.testng.TestRunner.privateRun(TestRunner.java:773)
	at org.testng.TestRunner.run(TestRunner.java:623)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
	at org.testng.TestNG.run(TestNG.java:1018)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
	at java.base/jdk.internal.jmod.JmodFile.checkMagic(JmodFile.java:62)
	at java.base/jdk.internal.jmod.JmodFile.<init>(JmodFile.java:180)
	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:392)
	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
	at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284)
	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232)
	... 44 more

java.lang.Exception: failures: 1
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)

So if you don't mind, I'll revert the latest commit

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

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

From alanb at openjdk.java.net  Sun Mar 14 17:43:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 17:43:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v2]
In-Reply-To: <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
 <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
Message-ID: <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>

On Sun, 14 Mar 2021 17:34:12 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 58:
>> 
>>> 56:             byte[] magic = in.readNBytes(4);
>>> 57:             if (magic.length != 4) {
>>> 58:                 throw new IOException("Header expected to be of length 4, but was " + magic.length);
>> 
>> Thanks for the update. If magic != 4 then it means the file is not a JMOD file or that it has been truncated.
>
> It turned out, that with this latest update some of tier2_tools tests are failing, e.g. `JLinkNegativeTest`:
> test JLinkNegativeTest.testMalformedJmod(): failure
> java.lang.AssertionError: Output does not fit regexp: Error: java.io.IOException: Invalid JMOD file
> 	at tests.Result.assertFailure(Result.java:70)
> 	at JLinkNegativeTest.testMalformedJmod(JLinkNegativeTest.java:201)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:773)
> 	at org.testng.TestRunner.run(TestRunner.java:623)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
> 	at org.testng.TestNG.run(TestNG.java:1018)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
> 	at java.base/java.lang.Thread.run(Thread.java:831)
> ...
> java.lang.module.FindException: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
> 	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:253)
> 	at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190)
> 	at java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154)
> 	at java.base/java.lang.module.Resolver.findWithBeforeFinder(Resolver.java:842)
> 	at java.base/java.lang.module.Resolver.resolve(Resolver.java:119)
> 	at java.base/java.lang.module.Configuration.resolve(Configuration.java:421)
> 	at java.base/java.lang.module.Configuration.resolve(Configuration.java:255)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.limitFinder(JlinkTask.java:545)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:466)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:65)
> 	at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
> 	at tests.Helper.generateDefaultImage(Helper.java:257)
> 	at tests.Helper.generateDefaultImage(Helper.java:244)
> 	at JLinkNegativeTest.testSectionsAreFiles(JLinkNegativeTest.java:307)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:773)
> 	at org.testng.TestRunner.run(TestRunner.java:623)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
> 	at org.testng.TestNG.run(TestNG.java:1018)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
> 	at java.base/java.lang.Thread.run(Thread.java:831)
> Caused by: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
> 	at java.base/jdk.internal.jmod.JmodFile.checkMagic(JmodFile.java:62)
> 	at java.base/jdk.internal.jmod.JmodFile.<init>(JmodFile.java:180)
> 	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:392)
> 	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
> 	at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284)
> 	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232)
> 	... 44 more
> 
> java.lang.Exception: failures: 1
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
> 	at java.base/java.lang.Thread.run(Thread.java:831)
> 
> So if you don't mind, I'll revert the latest commit

JLinkNegativeTest depends on the exception message, it should be easy to update.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 19:35:25 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 19:35:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v3]
In-Reply-To: <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
 <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
 <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>
Message-ID: <mBzztFpUt7brdGHXQz2gvLsU2GM8xiNI8K8cSESuxKU=.4928c4bf-7cef-4213-92b8-b6cfa63cb889@github.com>

On Sun, 14 Mar 2021 17:40:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It turned out, that with this latest update some of tier2_tools tests are failing, e.g. `JLinkNegativeTest`:
>> test JLinkNegativeTest.testMalformedJmod(): failure
>> java.lang.AssertionError: Output does not fit regexp: Error: java.io.IOException: Invalid JMOD file
>> 	at tests.Result.assertFailure(Result.java:70)
>> 	at JLinkNegativeTest.testMalformedJmod(JLinkNegativeTest.java:201)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>> 	at org.testng.TestRunner.privateRun(TestRunner.java:773)
>> 	at org.testng.TestRunner.run(TestRunner.java:623)
>> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>> 	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>> 	at org.testng.TestNG.run(TestNG.java:1018)
>> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
>> 	at java.base/java.lang.Thread.run(Thread.java:831)
>> ...
>> java.lang.module.FindException: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
>> 	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:253)
>> 	at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190)
>> 	at java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154)
>> 	at java.base/java.lang.module.Resolver.findWithBeforeFinder(Resolver.java:842)
>> 	at java.base/java.lang.module.Resolver.resolve(Resolver.java:119)
>> 	at java.base/java.lang.module.Configuration.resolve(Configuration.java:421)
>> 	at java.base/java.lang.module.Configuration.resolve(Configuration.java:255)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.limitFinder(JlinkTask.java:545)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:466)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267)
>> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
>> 	at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:65)
>> 	at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
>> 	at tests.Helper.generateDefaultImage(Helper.java:257)
>> 	at tests.Helper.generateDefaultImage(Helper.java:244)
>> 	at JLinkNegativeTest.testSectionsAreFiles(JLinkNegativeTest.java:307)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>> 	at org.testng.TestRunner.privateRun(TestRunner.java:773)
>> 	at org.testng.TestRunner.run(TestRunner.java:623)
>> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>> 	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>> 	at org.testng.TestNG.run(TestNG.java:1018)
>> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
>> 	at java.base/java.lang.Thread.run(Thread.java:831)
>> Caused by: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
>> 	at java.base/jdk.internal.jmod.JmodFile.checkMagic(JmodFile.java:62)
>> 	at java.base/jdk.internal.jmod.JmodFile.<init>(JmodFile.java:180)
>> 	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:392)
>> 	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
>> 	at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284)
>> 	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232)
>> 	... 44 more
>> 
>> java.lang.Exception: failures: 1
>> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
>> 	at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>> So if you don't mind, I'll revert the latest commit
>
> JLinkNegativeTest depends on the exception message, it should be easy to update.

Done

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 19:35:25 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 19:35:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v3]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Use InputStream.readNBytes() and fix JLinkNegativeTest

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/12505d05..a016d2ac

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

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

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

From prr at openjdk.java.net  Sun Mar 14 20:04:08 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 14 Mar 2021 20:04:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v3]
In-Reply-To: <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
Message-ID: <qu-3wpCTWHtKie-OZiBFMOUARfH_Y5HBfYJBAtxjh1o=.e77e6651-d64f-44fd-a375-f18206425718@github.com>

On Sun, 14 Mar 2021 19:35:25 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use InputStream.readNBytes() and fix JLinkNegativeTest

2d change is fine.

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

Marked as reviewed by prr (Reviewer).

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

From serb at openjdk.java.net  Sun Mar 14 22:51:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 14 Mar 2021 22:51:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v3]
In-Reply-To: <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
Message-ID: <lkZKaO6k53B25_oeC4aJO48gsmHH2MGnLi4q-Pl4WCA=.17a4f496-bf5f-4a66-aa3d-40ef746869a2@github.com>

On Sun, 14 Mar 2021 19:35:25 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use InputStream.readNBytes() and fix JLinkNegativeTest

src/java.desktop/share/classes/sun/awt/image/ByteArrayImageSource.java line 54:

> 52: 
> 53:     protected ImageDecoder getDecoder() {
> 54:         InputStream is = new ByteArrayInputStream(imagedata, imageoffset, imagelength);

This file use 80 chars per line code style.

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

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

From serb at openjdk.java.net  Mon Mar 15 06:26:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 15 Mar 2021 06:26:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Fd0YaskXedZoJtLWq7znep28VAt7_ks3HtvucSx7WJU=.fdc99e7a-5e24-436d-bf31-b388e57aac96@github.com>
Message-ID: <aG8r6s-n1kiik9upaMASlG_8mS1vfESVOFP8yv6qZg4=.852b9d25-d06e-4521-aac0-f69f3350a197@github.com>

On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas 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 47 additional commits since the last revision:
> 
>  - Lanai PR#214 - 8263324 - avu
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#213 - 8263325 - avu
>  - Lanai PR#212 - 8259825 - aghaisas
>  - Lanai PR#211 - 8262882 - aghaisas
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#210 - 8263159 - jdv
>  - Lanai PR#209 - 8262936 - jdv
>  - Lanai PR#208 - 8262928 - jdv
>  - Lanai PR#207 - 8262750 - jdv
>  - ... and 37 more: https://git.openjdk.java.net/jdk/compare/74f2d574...369c3d21

Marked as reviewed by serb (Reviewer).

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

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

From aghaisas at openjdk.java.net  Mon Mar 15 06:46:12 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 15 Mar 2021 06:46:12 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <73UylZ216N2glLW1mFF3E9mfpwCVrLm3MWXI-QlIXVU=.3dfd299b-127b-47a7-aba7-c842a4dc6c84@github.com>

On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

This pull request has now been integrated.

Changeset: 8afec70c
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8afec70c
Stats:     17612 lines in 87 files changed: 17573 ins; 2 del; 37 mod

8260931: Implement JEP 382: New macOS Rendering Pipeline

Co-authored-by: Jayathirth D V <jdv at openjdk.org>
Co-authored-by: Alexey Ushakov <avu at openjdk.org>
Co-authored-by: Artem Bochkarev <abochkarev at openjdk.org>
Co-authored-by: Prasanta Sadhukhan <psadhukhan at openjdk.org>
Co-authored-by: Denis Konoplev <dkonoplev at openjdk.org>
Co-authored-by: Phil Race <prr at openjdk.org>
Co-authored-by: Kevin Rushforth <kcr at openjdk.org>
Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Co-authored-by: Ajit Ghaisas <aghaisas at openjdk.org>
Reviewed-by: ihse, avu, kcr, gziemski, prr, kizune, jdv, psadhukhan, serb

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

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

From serb at openjdk.java.net  Mon Mar 15 07:04:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 15 Mar 2021 07:04:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8263467: Incorrect double-checked
 locking in sun.java2d.CRenderer
In-Reply-To: <DUQzb763KFDsDGZp81gQYSSsRnF7dYfzX_sUNEb75LY=.8b8c680d-c245-49b5-b01c-6759cf1289eb@github.com>
References: <ZAfgFTYJDWkDgRxjL7ImOf0t73VhZXsnZdamRe76x6o=.adb2a7e2-d92c-4a10-85be-f7a15b287da6@github.com>
 <zmmHhWjVPatEQUEtSBMUPHHU85LwF230DL0DabQPP-o=.56152a15-9d69-4611-b5d9-5d8caccab91f@github.com>
 <DUQzb763KFDsDGZp81gQYSSsRnF7dYfzX_sUNEb75LY=.8b8c680d-c245-49b5-b01c-6759cf1289eb@github.com>
Message-ID: <w8VlZc12SKQumR8R3mMOPGwYCN21_3FdHxJlOpxhwac=.20412fb0-d668-4382-a58e-1ff2a7585716@github.com>

On Fri, 12 Mar 2021 07:19:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Ok, I removed the "DCL" from that code and used the objects directly. AFAICS, synchronization is redundant on those local objects. What would be a good test for this change?

I guess that synchronization became redundant because the field was moved to the local var. But before that, it guarded the method in question for multithreaded access and that was not part of the DCL. So it will be better to return those fields back.

As the test I have run all automated tests and some manual tests, none of them triggered this code.

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

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

From avu at openjdk.java.net  Mon Mar 15 07:18:12 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 15 Mar 2021 07:18:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v10]
In-Reply-To: <JkDmLQYWsGlncXd5L7DOgEKhzV5S8lTVlfAUBQGRc4U=.d5b7e4d3-1831-417f-8ce0-b886966ac1f2@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <V4zzK9FCoBhQqjWubPG2elrEqTu4OjsPdlXuF4eRheo=.ee8f0f32-e299-4e04-bef5-6c1b51bf5a4a@github.com>
 <57_y3DUuOJ-FcWMueh_bCIt7LonAQW8l-guh_EQCv14=.bdcff4aa-e3b2-4f50-8e41-9b6ccf89c6fb@github.com>
 <vTEnRF92PmLsXlO-aHLfbQrs7Ao7mbhQ3y-zpDywaXg=.820a264c-c765-4bdb-a65a-9787eba1681f@github.com>
 <JkDmLQYWsGlncXd5L7DOgEKhzV5S8lTVlfAUBQGRc4U=.d5b7e4d3-1831-417f-8ce0-b886966ac1f2@github.com>
Message-ID: <fN-VCdwS_wBCvdsZeBU-piUiEwIBSlGNr13D8LLMZk8=.bd99bfcd-4ae0-48f6-afd8-681013ed987d@github.com>

On Fri, 12 Mar 2021 00:36:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I fixed some conversion logic within JDK-8256331.
>
> OK, just to confirm. I wrote that text for OGL because it was the fastest way to transfer+convert the data from the video card to the memory. And as far as I understand the metal has the same limitation? It is not possible to convert it to some non-ARGB/Pre format on the fly while transferring the pixles?

If we're talking about metal blit operation, the answer is No. Also, it looks like we still need a blit operation from video memory even if we use compute shader.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 08:36:29 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 08:36:29 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v3]
In-Reply-To: <lkZKaO6k53B25_oeC4aJO48gsmHH2MGnLi4q-Pl4WCA=.17a4f496-bf5f-4a66-aa3d-40ef746869a2@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
 <lkZKaO6k53B25_oeC4aJO48gsmHH2MGnLi4q-Pl4WCA=.17a4f496-bf5f-4a66-aa3d-40ef746869a2@github.com>
Message-ID: <LJayKKKnqxrRLYqVf5Kp3hGiZszs6pcuu71lAIwY7KQ=.c6b6d825-23a8-47e0-b13b-01e26f3e704a@github.com>

On Sun, 14 Mar 2021 22:48:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use InputStream.readNBytes() and fix JLinkNegativeTest
>
> src/java.desktop/share/classes/sun/awt/image/ByteArrayImageSource.java line 54:
> 
>> 52: 
>> 53:     protected ImageDecoder getDecoder() {
>> 54:         InputStream is = new ByteArrayInputStream(imagedata, imageoffset, imagelength);
> 
> This file use 80 chars per line code style.

Fixed.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 08:36:28 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 08:36:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v4]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <1QWRbOB-L164PKNpRWeJ9pY5AILrguO6Dv-OLhBB8UI=.d879ff21-7338-466e-9635-b69d9e5dcc9c@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Fix formatting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/a016d2ac..f69c8ff4

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

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

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

From dbatrak at openjdk.java.net  Mon Mar 15 10:31:36 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Mon, 15 Mar 2021 10:31:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
Message-ID: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>

This is the implementation used by JetBrains Runtime for the last 4 years, after some cleanup, and with one problem,
found while preparing the pull request, fixed.
Even though typical scenarios for a UI application should be covered, it's not a complete solution. In particular, emoji-s
still won't be rendered for large font sizes (more than 100pt), and for non-trivial composite/painting modes.
Notable implementation details are listed below.

**Glyph image generation**

Deprecated CGContextShowGlyphsAtPoint function, used by JDK on macOS to render text, cannot render emojis,
CTFontDrawGlyphs is used instead. It ignores the scale component of text transformation matrix, so a 'real-sized'
CTFont object should be passed to it. The same sizing procedure is done when calculating glyph metrics, because they
are not scaled proportionally with font size (as they do for vector fonts).

**Glyph image storage**

Existing GlyphInfo structure is used to store color glyph image. Color glyph can be distinguished by having 4 bytes
of storage per pixel. Color components are stored in pre-multiplied alpha format.

**Glyph rendering**

Previously, GlyphList instance always contained glyphs in the same format (solid, grayscale or LCD), determined by the
effective rendering hint. Now the renderers must be prepared to GlyphList having 'normal' glyphs interspersed with
color glyphs (they can appear due to font fallback). This isn't a problem for OpenGL renderer (used for on-screen painting),
but GlyphListLoopPipe-based renderers (used for off-screen painting) needed an adjustment to be able to operate on
specific segments of GlyphList.
As an incidental optimization, calculation of GlyphList bounds ('getBounds' method) is performed now only when needed
(most text renderers don't need this information).
Speaking of the actual rendering of the glyph image, it's done by the straightforward glDrawPixels call in OpenGL renderer,
and by re-using existing Blit primitive in off-screen renderers.

**Testing**

There's no good way to test the new functionality automatically, but I've added a test verifying that 'something' is
rendered for the emoji character, when painting to BufferedImage.

Existing tests pass after the change.

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

Commit messages:
 - 8263583: Emoji rendering on macOS

Changes: https://git.openjdk.java.net/jdk/pull/3007/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3007&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263583
  Stats: 816 lines in 28 files changed: 677 ins; 29 del; 110 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3007.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3007/head:pull/3007

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

From azvegint at openjdk.java.net  Mon Mar 15 10:50:13 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 15 Mar 2021 10:50:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux
In-Reply-To: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
Message-ID: <UOPCOlL9p-PXVQe6iYKZcZBWALYM4vXDXQtN7uFBYJY=.9b2fdcf3-3fe4-4bb1-b081-815633361d63@github.com>

On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race <prr at openjdk.org> wrote:

> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
> 
> I ended up having to go this way because its is the least unsatisfactory solution.
> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
> because too many systems have to old a version of harfbuzz.
> 
> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
> 
> There are couple of incidental fixes in here too
> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 465:

> 463:         tautological-constant-out-of-range-compare int-to-pointer-cast \
> 464:         undef missing-field-initializers range-loop-analysis
> 465:     HARFBUZZ_DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138

Looks like that this block has extra indent of 1 space.

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 479:

> 477:   # when building libharfbuzz
> 478:   ifeq ($(call isTargetOs, aix), true)
> 479:     LIBHARFBUZZ_CFLAGS += -qdebug=necan

I couldn't find the `-qdebug=necan` in the updated makefile. Does the [JDK-8258484](https://bugs.openjdk.java.net/browse/JDK-8258484) handled is some other way?

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

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

From alanb at openjdk.java.net  Mon Mar 15 11:45:09 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Mar 2021 11:45:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v4]
In-Reply-To: <mBzztFpUt7brdGHXQz2gvLsU2GM8xiNI8K8cSESuxKU=.4928c4bf-7cef-4213-92b8-b6cfa63cb889@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
 <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
 <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>
 <mBzztFpUt7brdGHXQz2gvLsU2GM8xiNI8K8cSESuxKU=.4928c4bf-7cef-4213-92b8-b6cfa63cb889@github.com>
Message-ID: <kTM5ChOIIfycb1HMhVPL8X-J5wwTUiQ2E5g_ivfNGE8=.ae6076bc-e8ea-4167-bc46-12fae4ace359@github.com>

On Sun, 14 Mar 2021 19:32:11 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Done

I think I'd prefer if the exception message would say that the JMOD is invalid or that the JMOD file is truncated (because I don't think anyone seeing this exception will know anything about the header).

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 12:19:19 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 12:19:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v5]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Fix error message

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/f69c8ff4..ff25cc4d

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 12:19:20 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 12:19:20 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v5]
In-Reply-To: <kTM5ChOIIfycb1HMhVPL8X-J5wwTUiQ2E5g_ivfNGE8=.ae6076bc-e8ea-4167-bc46-12fae4ace359@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
 <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
 <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>
 <mBzztFpUt7brdGHXQz2gvLsU2GM8xiNI8K8cSESuxKU=.4928c4bf-7cef-4213-92b8-b6cfa63cb889@github.com>
 <kTM5ChOIIfycb1HMhVPL8X-J5wwTUiQ2E5g_ivfNGE8=.ae6076bc-e8ea-4167-bc46-12fae4ace359@github.com>
Message-ID: <yMAfv0SBA75CqMmGml8nR6Gcbc0vtlEFzV8xX98yb_o=.695245e8-4b85-4f12-a351-810fcb50f2a5@github.com>

On Mon, 15 Mar 2021 11:41:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Done
>
>> Done
> 
> I think I'd prefer if the exception message would say that the JMOD is invalid or that the JMOD file is truncated (because I don't think anyone seeing this exception will know anything about the header).

Fixed

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

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

From ihse at openjdk.java.net  Mon Mar 15 12:29:15 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 15 Mar 2021 12:29:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux
In-Reply-To: <biJbAWHnKKS6bYO9vR5-cHEqzTOSKyyiZhPq2vLVFBQ=.dccc81c9-c986-400e-8beb-51d7fa096764@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <biJbAWHnKKS6bYO9vR5-cHEqzTOSKyyiZhPq2vLVFBQ=.dccc81c9-c986-400e-8beb-51d7fa096764@github.com>
Message-ID: <pp1zeln1-6IrU7NkzNutMxEdEF3jn32AMVKtgxPWlO4=.e59349b5-4286-4223-9ad0-9e2875b5f6bd@github.com>

On Sat, 13 Mar 2021 00:34:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory solution.
>> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> Marked as reviewed by serb (Reviewer).

It feels a bit unfortunate that we had to end up this way. :-( I've read through the bug report and unnderstand that this might be the least bad way... but still.

Just thinking out loud, you don't think it would be better to build harfbuzz separately, but as a static library, that is then included in libfontmanager? The main win of doing that, I think, is the ability to have all the disabled warnings confined to the lower-quality upstream source. The resulting code would be the same. And from a build performance perspective I don't think any way of doing it matters.

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

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

From alanb at openjdk.java.net  Mon Mar 15 13:48:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Mar 2021 13:48:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v5]
In-Reply-To: <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
Message-ID: <m9HYVx65pZQEN8sqoGogPmWS-15d2Ox0_10QtvBWGn0=.058a5e84-3dee-4e22-95c1-fa488aea1b70@github.com>

On Mon, 15 Mar 2021 12:19:19 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix error message

Marked as reviewed by alanb (Reviewer).

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

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

From dfuchs at openjdk.java.net  Mon Mar 15 15:08:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 15 Mar 2021 15:08:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v5]
In-Reply-To: <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
Message-ID: <bt6JnxMDiLjVjJ64IfNcMFlTT9a_s8ttcrqOCtCNIMw=.0b9a12d7-4b8d-4c93-9ed8-32f4b59e2053@github.com>

On Mon, 15 Mar 2021 12:19:19 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix error message

Changes requested by dfuchs (Reviewer).

src/java.base/share/classes/sun/net/www/http/HttpClient.java line 434:

> 432:                 int r = tmpbuf.read();
> 433:                 if (r == -1) {
> 434:                     logFinest("HttpClient.available(): " +

There are some subtle things going on there. Using a `BufferedInputStream` ensures that all the bytes available on the socket will be read, up to the buffer capacity. Can you revert this change? I'd rather that this clean up be handled separately. I have logged https://bugs.openjdk.java.net/browse/JDK-8263599.

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

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

From avu at openjdk.java.net  Mon Mar 15 16:02:13 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 15 Mar 2021 16:02:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
Message-ID: <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>

On Mon, 15 Mar 2021 10:25:50 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> This is the implementation used by JetBrains Runtime for the last 4 years, after some cleanup, and with one problem,
> found while preparing the pull request, fixed.
> Even though typical scenarios for a UI application should be covered, it's not a complete solution. In particular, emoji-s
> still won't be rendered for large font sizes (more than 100pt), and for non-trivial composite/painting modes.
> Notable implementation details are listed below.
> 
> **Glyph image generation**
> 
> Deprecated CGContextShowGlyphsAtPoint function, used by JDK on macOS to render text, cannot render emojis,
> CTFontDrawGlyphs is used instead. It ignores the scale component of text transformation matrix, so a 'real-sized'
> CTFont object should be passed to it. The same sizing procedure is done when calculating glyph metrics, because they
> are not scaled proportionally with font size (as they do for vector fonts).
> 
> **Glyph image storage**
> 
> Existing GlyphInfo structure is used to store color glyph image. Color glyph can be distinguished by having 4 bytes
> of storage per pixel. Color components are stored in pre-multiplied alpha format.
> 
> **Glyph rendering**
> 
> Previously, GlyphList instance always contained glyphs in the same format (solid, grayscale or LCD), determined by the
> effective rendering hint. Now the renderers must be prepared to GlyphList having 'normal' glyphs interspersed with
> color glyphs (they can appear due to font fallback). This isn't a problem for OpenGL renderer (used for on-screen painting),
> but GlyphListLoopPipe-based renderers (used for off-screen painting) needed an adjustment to be able to operate on
> specific segments of GlyphList.
> As an incidental optimization, calculation of GlyphList bounds ('getBounds' method) is performed now only when needed
> (most text renderers don't need this information).
> Speaking of the actual rendering of the glyph image, it's done by the straightforward glDrawPixels call in OpenGL renderer,
> and by re-using existing Blit primitive in off-screen renderers.
> 
> **Testing**
> 
> There's no good way to test the new functionality automatically, but I've added a test verifying that 'something' is
> rendered for the emoji character, when painting to BufferedImage.
> 
> Existing tests pass after the change.

Looks good

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 17:56:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 17:56:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v5]
In-Reply-To: <bt6JnxMDiLjVjJ64IfNcMFlTT9a_s8ttcrqOCtCNIMw=.0b9a12d7-4b8d-4c93-9ed8-32f4b59e2053@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
 <bt6JnxMDiLjVjJ64IfNcMFlTT9a_s8ttcrqOCtCNIMw=.0b9a12d7-4b8d-4c93-9ed8-32f4b59e2053@github.com>
Message-ID: <fnnHKy_PXoUoF5XhxlLinChVMRSa3t0Ap7km0xtHB5w=.5c9b320e-88f3-486e-a9c3-fb760b3afc0f@github.com>

On Mon, 15 Mar 2021 15:04:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix error message
>
> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 434:
> 
>> 432:                 int r = tmpbuf.read();
>> 433:                 if (r == -1) {
>> 434:                     logFinest("HttpClient.available(): " +
> 
> There are some subtle things going on there. Using a `BufferedInputStream` ensures that all the bytes available on the socket will be read, up to the buffer capacity. Can you revert this change? I'd rather that this clean up be handled separately. I have logged https://bugs.openjdk.java.net/browse/JDK-8263599.

Sure, I'll revert this.

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

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

From dfuchs at openjdk.java.net  Mon Mar 15 18:04:27 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 15 Mar 2021 18:04:27 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v6]
In-Reply-To: <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>
Message-ID: <PD2i1PmLCggQzIlT8L_3Frc84BO-rR02_EAMZlPzOeU=.78f43282-f265-4c09-8eb1-7b009f7ca710@github.com>

On Mon, 15 Mar 2021 18:01:20 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert HttpClient

LGTM. Thanks!

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

Marked as reviewed by dfuchs (Reviewer).

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

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 18:04:26 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 18:04:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v6]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Revert HttpClient

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/ff25cc4d..af4fcce4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=04-05

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

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

From akozlov at openjdk.java.net  Mon Mar 15 18:23:35 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:23:35 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v28]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <hz2vrgXQiBRvuTHp7eiZpkHoAcoMYXlEk-X-hfoJsYo=.a43951e9-c93b-4659-b2b1-ecfdedffad20@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits:

 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch
 - 8262903: [macos_aarch64] Thread::current() called on detached thread
 - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
 - ... and 104 more: https://git.openjdk.java.net/jdk/compare/d825198e...806fc618

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=27
  Stats: 2949 lines in 75 files changed: 2839 ins; 27 del; 83 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From prr at openjdk.java.net  Mon Mar 15 18:38:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 15 Mar 2021 18:38:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux
In-Reply-To: <UOPCOlL9p-PXVQe6iYKZcZBWALYM4vXDXQtN7uFBYJY=.9b2fdcf3-3fe4-4bb1-b081-815633361d63@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <UOPCOlL9p-PXVQe6iYKZcZBWALYM4vXDXQtN7uFBYJY=.9b2fdcf3-3fe4-4bb1-b081-815633361d63@github.com>
Message-ID: <1pxtHEdYSkesEdKlPqRXRm3eMs0RuqUbqiyXpUpWadM=.4c8eb452-eceb-40a5-b9f3-dea309803765@github.com>

On Mon, 15 Mar 2021 10:46:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory solution.
>> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 479:
> 
>> 477:   # when building libharfbuzz
>> 478:   ifeq ($(call isTargetOs, aix), true)
>> 479:     LIBHARFBUZZ_CFLAGS += -qdebug=necan
> 
> I couldn't find the `-qdebug=necan` in the updated makefile. Is the [JDK-8258484](https://bugs.openjdk.java.net/browse/JDK-8258484) handled in some other way?

I'll restore this.

> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 465:
> 
>> 463:         tautological-constant-out-of-range-compare int-to-pointer-cast \
>> 464:         undef missing-field-initializers range-loop-analysis
>> 465:     HARFBUZZ_DISABLED_WARNINGS_microsoft := 4267 4244 4090 4146 4334 4819 4101 4068 4805 4138
> 
> Looks like that this block has extra indent of 1 space.

Yes, I'll update it.

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

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

From prr at openjdk.java.net  Mon Mar 15 18:38:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 15 Mar 2021 18:38:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux
In-Reply-To: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
Message-ID: <zRyxk5FD0JCgfoD2DU3dLPJ6h2u6kgWtq1nwGJNqs8Y=.716ff2cc-775a-420b-a53b-d46dee52bab2@github.com>

On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race <prr at openjdk.org> wrote:

> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
> 
> I ended up having to go this way because its is the least unsatisfactory solution.
> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
> because too many systems have to old a version of harfbuzz.
> 
> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
> 
> There are couple of incidental fixes in here too
> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502

> Just thinking out loud, you don't think it would be better to build harfbuzz separately, but as a static library, that is then included in libfontmanager? The main win of doing that, I think, is the ability to have all the disabled warnings confined to the lower-quality upstream source. The resulting code would be the same. And from a build performance perspective I don't think any way of doing it matters.

I don't know that this would be worth such an effort. I've clearly separated the warnings we are disabling for HARFBUZZ and there's really not a lot of likelihood in my mind that these warnings will suddenly also start to apply to the small amount of JDK code that is in libfontmanager which is also much simpler code.

BTW I noticed we are still disabling all warnings for sunFont.c and after this is done I'll likely see if I can make a source code change to resolve that.

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

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

From akozlov at openjdk.java.net  Mon Mar 15 18:56:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:56:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v12]
In-Reply-To: <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
 <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>
 <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com>
Message-ID: <v4LN5mBL_UaL1YxXlwj4CLuvo9lQU5yHY_3e5MQQ1g8=.0783fcae-d399-4a76-94e7-73ef68133941@github.com>

On Thu, 11 Mar 2021 20:27:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. 
>> 
>> In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR.
>
> Good point about Thread vs JavaThread. Yes, this can be looked into as follow-up cleanups.

The enhancement is tracked in https://bugs.openjdk.java.net/browse/JDK-8263492

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

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

From akozlov at openjdk.java.net  Mon Mar 15 18:56:17 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:56:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v21]
In-Reply-To: <SXXcMmMTXbltmXqeaDgF6g8EJvECwqtlNokXpNJ0CNI=.f358e952-3186-4503-a632-834ec4343c6d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
 <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
 <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>
 <SXXcMmMTXbltmXqeaDgF6g8EJvECwqtlNokXpNJ0CNI=.f358e952-3186-4503-a632-834ec4343c6d@github.com>
Message-ID: <4EryfweVy9Q97cbm7rAcsSIXuK2XImbIfuPeloJuXEA=.90a1f396-299c-43d2-922b-9af36ca43467@github.com>

On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
>
> Robustness, clarity, maintainability, convention. Why not?

I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`). The rest of the defines in this file follows the pattern: a define without a value to be checked with `#ifdef` and define with a value to be checked with `#if`. To be consistent, I would need to add `#define R18_RESERVED false` to the `#else` clause and change every `#ifdef R18_RESERVED`/`#ifndef R18_RESERVED` to `#if R18_RESERVED`/`#if !R18_RESERVED`. I think we'll win in clarity in the long term if I will not implement the suggestion without related changes. (And related changes would introduce additional noise, which we are fighting with).

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

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

From akozlov at openjdk.java.net  Mon Mar 15 18:56:23 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:56:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v28]
In-Reply-To: <FB2pev3OL8y-AYtFw1i8n3Np5ny9bYb8wdduqVtiXhA=.84f450cc-6891-4a0b-a84d-1abb8a2eaf00@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>
 <FB2pev3OL8y-AYtFw1i8n3Np5ny9bYb8wdduqVtiXhA=.84f450cc-6891-4a0b-a84d-1abb8a2eaf00@github.com>
Message-ID: <0dFnMCcGeahDTezdMqNQ2ZtipjeEaCpNezow6Kqy5xE=.ec72c0d8-8252-4abf-ab7a-8ce4b89ca527@github.com>

On Sat, 13 Mar 2021 05:49:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits:
>> 
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>>  - ... and 104 more: https://git.openjdk.java.net/jdk/compare/d825198e...806fc618
>
> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
> 
>> 33: inline int SafeFetch32(int* adr, int errValue) {
>> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>> 35:   Thread* thread = Thread::current_or_null_safe();
> 
> Sorry but this should be MACOS_AARCH64 only. All three lines need to be ifdef'd if you are going to include the assertion.
> 
> Thanks,
> David

Right, thanks! Fixed in https://github.com/openjdk/jdk/pull/2200/commits/3d0f4d2342adc867eaf762fa83a9c3035d6439bd

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

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

From ihse at openjdk.java.net  Mon Mar 15 18:57:28 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 15 Mar 2021 18:57:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux [v2]
In-Reply-To: <zRyxk5FD0JCgfoD2DU3dLPJ6h2u6kgWtq1nwGJNqs8Y=.716ff2cc-775a-420b-a53b-d46dee52bab2@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <zRyxk5FD0JCgfoD2DU3dLPJ6h2u6kgWtq1nwGJNqs8Y=.716ff2cc-775a-420b-a53b-d46dee52bab2@github.com>
Message-ID: <ZX1RnDBMdzjYswl1IUj2nC88Ju62vbvpEaFXuhq1f24=.8b9535c7-9dcb-4725-ba4c-17ef71e5b837@github.com>

On Mon, 15 Mar 2021 18:35:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux
>
>> Just thinking out loud, you don't think it would be better to build harfbuzz separately, but as a static library, that is then included in libfontmanager? The main win of doing that, I think, is the ability to have all the disabled warnings confined to the lower-quality upstream source. The resulting code would be the same. And from a build performance perspective I don't think any way of doing it matters.
> 
> I don't know that this would be worth such an effort. I've clearly separated the warnings we are disabling for HARFBUZZ and there's really not a lot of likelihood in my mind that these warnings will suddenly also start to apply to the small amount of JDK code that is in libfontmanager which is also much simpler code.
> 
> BTW I noticed we are still disabling all warnings for sunFont.c and after this is done I'll likely see if I can make a source code change to resolve that.

I was actually thinking that such a change would be simpler; more or less amounting to changing from LIBRARY to STATIC_LIBRARY. But if you feel that it is too much work, fine...

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

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

From prr at openjdk.java.net  Mon Mar 15 18:57:28 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 15 Mar 2021 18:57:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux [v2]
In-Reply-To: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
Message-ID: <Hwxy-ni7-3IE5vbgUMaPlbUca3s_eJ0ZWecs90u201o=.4172b772-83d9-47cd-83a8-9685dea62d68@github.com>

> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
> 
> I ended up having to go this way because its is the least unsatisfactory solution.
> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
> because too many systems have to old a version of harfbuzz.
> 
> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
> 
> There are couple of incidental fixes in here too
> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2982/files
  - new: https://git.openjdk.java.net/jdk/pull/2982/files/29d3e4b2..f668b327

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

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

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

From prr at openjdk.java.net  Mon Mar 15 19:07:09 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 15 Mar 2021 19:07:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux [v2]
In-Reply-To: <ZX1RnDBMdzjYswl1IUj2nC88Ju62vbvpEaFXuhq1f24=.8b9535c7-9dcb-4725-ba4c-17ef71e5b837@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <zRyxk5FD0JCgfoD2DU3dLPJ6h2u6kgWtq1nwGJNqs8Y=.716ff2cc-775a-420b-a53b-d46dee52bab2@github.com>
 <ZX1RnDBMdzjYswl1IUj2nC88Ju62vbvpEaFXuhq1f24=.8b9535c7-9dcb-4725-ba4c-17ef71e5b837@github.com>
Message-ID: <T9RcyjzlVTlMI-Iu0Jot0gN6oNAdYhX4DO3vh-6eLwE=.79bf3ba8-e122-43f1-8ddc-b330847dc5a1@github.com>

On Mon, 15 Mar 2021 18:52:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I was actually thinking that such a change would be simpler; more or less amounting to changing from LIBRARY to STATIC_LIBRARY. But if you feel that it is too much work, fine...

If you say so .. I have no idea what build changes would be needed. I'm just more familiar and comfortable with this and leaving aside the graal stuff I don't know if it is used like that anywhere by the main JDK build.

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

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

From ihse at openjdk.java.net  Mon Mar 15 20:17:08 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 15 Mar 2021 20:17:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux [v2]
In-Reply-To: <Hwxy-ni7-3IE5vbgUMaPlbUca3s_eJ0ZWecs90u201o=.4172b772-83d9-47cd-83a8-9685dea62d68@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <Hwxy-ni7-3IE5vbgUMaPlbUca3s_eJ0ZWecs90u201o=.4172b772-83d9-47cd-83a8-9685dea62d68@github.com>
Message-ID: <fL97QNKPULIUdkNi6DOTVo50S_E83NXEQ1SWs_yD23Y=.2403825f-f146-4ac2-a3c1-8f74896b9fe9@github.com>

On Mon, 15 Mar 2021 18:57:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory solution.
>> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Marked as reviewed by ihse (Reviewer).

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

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

From prr at openjdk.java.net  Mon Mar 15 23:50:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 15 Mar 2021 23:50:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
 <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>
Message-ID: <RtpTWeSKgDVs0BKBbTrtGrWTzKLM2aW0_hUo0gni1-k=.952189ee-ffd6-4962-9541-d7c9888e9dbe@github.com>

On Mon, 15 Mar 2021 15:59:36 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> This is the implementation used by JetBrains Runtime for the last 4 years, after some cleanup, and with one problem,
>> found while preparing the pull request, fixed.
>> Even though typical scenarios for a UI application should be covered, it's not a complete solution. In particular, emoji-s
>> still won't be rendered for large font sizes (more than 100pt), and for non-trivial composite/painting modes.
>> Notable implementation details are listed below.
>> 
>> **Glyph image generation**
>> 
>> Deprecated CGContextShowGlyphsAtPoint function, used by JDK on macOS to render text, cannot render emojis,
>> CTFontDrawGlyphs is used instead. It ignores the scale component of text transformation matrix, so a 'real-sized'
>> CTFont object should be passed to it. The same sizing procedure is done when calculating glyph metrics, because they
>> are not scaled proportionally with font size (as they do for vector fonts).
>> 
>> **Glyph image storage**
>> 
>> Existing GlyphInfo structure is used to store color glyph image. Color glyph can be distinguished by having 4 bytes
>> of storage per pixel. Color components are stored in pre-multiplied alpha format.
>> 
>> **Glyph rendering**
>> 
>> Previously, GlyphList instance always contained glyphs in the same format (solid, grayscale or LCD), determined by the
>> effective rendering hint. Now the renderers must be prepared to GlyphList having 'normal' glyphs interspersed with
>> color glyphs (they can appear due to font fallback). This isn't a problem for OpenGL renderer (used for on-screen painting),
>> but GlyphListLoopPipe-based renderers (used for off-screen painting) needed an adjustment to be able to operate on
>> specific segments of GlyphList.
>> As an incidental optimization, calculation of GlyphList bounds ('getBounds' method) is performed now only when needed
>> (most text renderers don't need this information).
>> Speaking of the actual rendering of the glyph image, it's done by the straightforward glDrawPixels call in OpenGL renderer,
>> and by re-using existing Blit primitive in off-screen renderers.
>> 
>> **Testing**
>> 
>> There's no good way to test the new functionality automatically, but I've added a test verifying that 'something' is
>> rendered for the emoji character, when painting to BufferedImage.
>> 
>> Existing tests pass after the change.
>
> Looks good

Initial testing it looks OK with OpenGL but it renders as garbage with the metal pipeline.
I'd guess metal isn't expecting 4bpp and the stride is wrong.
Since metal is now integrated this should be fixed before this change can be pushed.

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

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

From serb at openjdk.java.net  Tue Mar 16 00:35:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 00:35:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
Message-ID: <_17q6oezauvliTJEyLver5e_sBQ4B12LC6p4rPakjhM=.6285b5a8-2171-4575-b9e8-2d17aa35e9f7@github.com>

On Mon, 15 Mar 2021 10:25:50 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> This is the implementation used by JetBrains Runtime for the last 4 years, after some cleanup, and with one problem,
> found while preparing the pull request, fixed.
> Even though typical scenarios for a UI application should be covered, it's not a complete solution. In particular, emoji-s
> still won't be rendered for large font sizes (more than 100pt), and for non-trivial composite/painting modes.
> Notable implementation details are listed below.
> 
> **Glyph image generation**
> 
> Deprecated CGContextShowGlyphsAtPoint function, used by JDK on macOS to render text, cannot render emojis,
> CTFontDrawGlyphs is used instead. It ignores the scale component of text transformation matrix, so a 'real-sized'
> CTFont object should be passed to it. The same sizing procedure is done when calculating glyph metrics, because they
> are not scaled proportionally with font size (as they do for vector fonts).
> 
> **Glyph image storage**
> 
> Existing GlyphInfo structure is used to store color glyph image. Color glyph can be distinguished by having 4 bytes
> of storage per pixel. Color components are stored in pre-multiplied alpha format.
> 
> **Glyph rendering**
> 
> Previously, GlyphList instance always contained glyphs in the same format (solid, grayscale or LCD), determined by the
> effective rendering hint. Now the renderers must be prepared to GlyphList having 'normal' glyphs interspersed with
> color glyphs (they can appear due to font fallback). This isn't a problem for OpenGL renderer (used for on-screen painting),
> but GlyphListLoopPipe-based renderers (used for off-screen painting) needed an adjustment to be able to operate on
> specific segments of GlyphList.
> As an incidental optimization, calculation of GlyphList bounds ('getBounds' method) is performed now only when needed
> (most text renderers don't need this information).
> Speaking of the actual rendering of the glyph image, it's done by the straightforward glDrawPixels call in OpenGL renderer,
> and by re-using existing Blit primitive in off-screen renderers.
> 
> **Testing**
> 
> There's no good way to test the new functionality automatically, but I've added a test verifying that 'something' is
> rendered for the emoji character, when painting to BufferedImage.
> 
> Existing tests pass after the change.

src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListColor.java line 71:

> 69:     static {
> 70:         GraphicsPrimitiveMgr.registerGeneral(
> 71:                                 new DrawGlyphListColor(null, null, null));

If it is a complete "General" loop which supports all possible combination of incoming src/comp/dst/transform/etc I suggest to confirm that in the test.

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

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

From serb at openjdk.java.net  Tue Mar 16 00:36:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 00:36:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263560: Remove needless wrapping with
 BufferedInputStream [v6]
In-Reply-To: <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>
Message-ID: <ymP892-NKnsza-5llGFP9_uSdg7BR3SW4Fvmqan23V4=.b1864466-478e-4404-af7e-18cbd59c13b5@github.com>

On Mon, 15 Mar 2021 18:04:26 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert HttpClient

Marked as reviewed by serb (Reviewer).

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

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

From dbatrak at openjdk.java.net  Tue Mar 16 05:13:07 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Tue, 16 Mar 2021 05:13:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <RtpTWeSKgDVs0BKBbTrtGrWTzKLM2aW0_hUo0gni1-k=.952189ee-ffd6-4962-9541-d7c9888e9dbe@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
 <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>
 <RtpTWeSKgDVs0BKBbTrtGrWTzKLM2aW0_hUo0gni1-k=.952189ee-ffd6-4962-9541-d7c9888e9dbe@github.com>
Message-ID: <9-0Gtuwqcg22dWmmXwr6eSOF_hSxEpA3J-F4Mc-rdYY=.12820f83-bf7e-453f-a262-da82c7001087@github.com>

On Mon, 15 Mar 2021 23:47:16 GMT, Phil Race <prr at openjdk.org> wrote:

> Initial testing it looks OK with OpenGL but it renders as garbage with the metal pipeline.
> I'd guess metal isn't expecting 4bpp and the stride is wrong.
> I see updates in OGLTextRenderer so something similar likely needed for metal.
> Since metal is now integrated this should be fixed before this change can be pushed.

I'm going to add Metal implementation soon.

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

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

From dbatrak at openjdk.java.net  Tue Mar 16 08:53:15 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Tue, 16 Mar 2021 08:53:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <9-0Gtuwqcg22dWmmXwr6eSOF_hSxEpA3J-F4Mc-rdYY=.12820f83-bf7e-453f-a262-da82c7001087@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
 <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>
 <RtpTWeSKgDVs0BKBbTrtGrWTzKLM2aW0_hUo0gni1-k=.952189ee-ffd6-4962-9541-d7c9888e9dbe@github.com>
 <9-0Gtuwqcg22dWmmXwr6eSOF_hSxEpA3J-F4Mc-rdYY=.12820f83-bf7e-453f-a262-da82c7001087@github.com>
Message-ID: <auyqIoUUeLpZr-pRga_n1W2p9W95MFQnfot_0Vj6Wyk=.28acfb50-62af-4670-b3a0-f77b181d3371@github.com>

On Tue, 16 Mar 2021 05:10:05 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> Initial testing it looks OK with OpenGL but it renders as garbage with the metal pipeline.
>> I'd guess metal isn't expecting 4bpp and the stride is wrong.
>> I see updates in OGLTextRenderer so something similar likely needed for metal.
>> Since metal is now integrated this should be fixed before this change can be pushed.
>
>> Initial testing it looks OK with OpenGL but it renders as garbage with the metal pipeline.
>> I'd guess metal isn't expecting 4bpp and the stride is wrong.
>> I see updates in OGLTextRenderer so something similar likely needed for metal.
>> Since metal is now integrated this should be fixed before this change can be pushed.
> 
> I'm going to add Metal implementation soon.

> If it is a complete "General" loop which supports all possible combination of incoming src/comp/dst/transform/etc I suggest to confirm that in the test.

@mrserb This code is currently only used by GlyphListLoopPipe-based text renderers (SolidTextRenderer, AATextRenderer, LCDTextRenderer), so it won't be invoked for arbitrary composites and paint types. But different destination types (image formats) and transforms are supported.

What kind of test are you having in mind? I can extend the added MacEmoji.java test, that will check that 'something' is painted to different types of BufferedImage-s and/or with transforms applied. Or you want me to add a manual test case?

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

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

From azvegint at openjdk.java.net  Tue Mar 16 10:42:10 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 16 Mar 2021 10:42:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux [v2]
In-Reply-To: <Hwxy-ni7-3IE5vbgUMaPlbUca3s_eJ0ZWecs90u201o=.4172b772-83d9-47cd-83a8-9685dea62d68@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <Hwxy-ni7-3IE5vbgUMaPlbUca3s_eJ0ZWecs90u201o=.4172b772-83d9-47cd-83a8-9685dea62d68@github.com>
Message-ID: <Jn9bnpHc-AiDsZzQ04i9QcY_GoNnuSeswRMinHRW_AQ=.6ca43cd9-81dd-4dd8-9c68-60bc372a5f29@github.com>

On Mon, 15 Mar 2021 18:57:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory solution.
>> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 456:

> 454:    # when building libharfbuzz
> 455:    ifeq ($(call isTargetOs, aix), true)
> 456:      LIBHARFBUZZ_CFLAGS += -qdebug=necan

Should it be `HARFBUZZ_CFLAGS` instead of `LIBHARFBUZZ_CFLAGS`? I don't see any usage of `LIBHARFBUZZ_CFLAGS` in this makefile.

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

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

From prr at openjdk.java.net  Tue Mar 16 16:56:23 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 16 Mar 2021 16:56:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux [v2]
In-Reply-To: <Jn9bnpHc-AiDsZzQ04i9QcY_GoNnuSeswRMinHRW_AQ=.6ca43cd9-81dd-4dd8-9c68-60bc372a5f29@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <Hwxy-ni7-3IE5vbgUMaPlbUca3s_eJ0ZWecs90u201o=.4172b772-83d9-47cd-83a8-9685dea62d68@github.com>
 <Jn9bnpHc-AiDsZzQ04i9QcY_GoNnuSeswRMinHRW_AQ=.6ca43cd9-81dd-4dd8-9c68-60bc372a5f29@github.com>
Message-ID: <u6oY6_kIPuJ29Iq3jujZqsfw1GZ5CXgow_AfKeikUaY=.9ae14a86-712c-412d-8dea-4b30d5a576ce@github.com>

On Tue, 16 Mar 2021 10:38:19 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 456:
> 
>> 454:    # when building libharfbuzz
>> 455:    ifeq ($(call isTargetOs, aix), true)
>> 456:      LIBHARFBUZZ_CFLAGS += -qdebug=necan
> 
> Should it be `HARFBUZZ_CFLAGS` instead of `LIBHARFBUZZ_CFLAGS`? I don't see any usage of `LIBHARFBUZZ_CFLAGS` in this makefile.

D'oh. It was LIB* in the old code and I copy / pasted and of course can't test that.
I've uploaded a fix.

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

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

From prr at openjdk.java.net  Tue Mar 16 16:56:22 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 16 Mar 2021 16:56:22 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux [v3]
In-Reply-To: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
Message-ID: <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>

> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
> 
> I ended up having to go this way because its is the least unsatisfactory solution.
> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
> because too many systems have to old a version of harfbuzz.
> 
> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
> 
> There are couple of incidental fixes in here too
> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2982/files
  - new: https://git.openjdk.java.net/jdk/pull/2982/files/f668b327..a92a146c

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

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

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

From ihse at openjdk.java.net  Tue Mar 16 18:14:07 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 16 Mar 2021 18:14:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux [v3]
In-Reply-To: <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
Message-ID: <UzOHDjH4fLzAyHkDgtHS1oyUsa9b1MkZ9jbO9TOGUsk=.c203d618-f95d-4ef1-964f-8aa750007244@github.com>

On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory solution.
>> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Marked as reviewed by ihse (Reviewer).

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

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

From azvegint at openjdk.java.net  Tue Mar 16 19:30:09 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 16 Mar 2021 19:30:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux [v3]
In-Reply-To: <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
 <Dd1tpX41xYE43y7GoNxSiApEHoniYEx3YcpbQGCwOmE=.d9146b76-b2e9-4f37-aa4b-b4d7a96c6ba2@github.com>
Message-ID: <tW3NeY3rmFhgoWvNf7XBpP185FTmCnjlPVt0G6z0XSk=.cc21ee3c-7fbd-4b4d-b743-6a5adf7cfd32@github.com>

On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
>> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
>> 
>> I ended up having to go this way because its is the least unsatisfactory solution.
>> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
>> because too many systems have to old a version of harfbuzz.
>> 
>> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
>> 
>> There are couple of incidental fixes in here too
>> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
>> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
>> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Marked as reviewed by azvegint (Reviewer).

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

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

From prr at openjdk.java.net  Tue Mar 16 19:39:11 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 16 Mar 2021 19:39:11 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8255790: GTKL&F: Java 16 crashes on
 initialising GTKL&F on Manjaro Linux
In-Reply-To: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
References: <dm4sd0EsT5QHd7G-ZLZckOtT3lV-imdu2765_ViXYek=.6e21169c-60ca-4615-bb87-e6ca86036403@github.com>
Message-ID: <hPUB914FmwX6M7tKTFvIPCvHZP7LBqpwoLKHou2MahM=.8fb265f7-32f0-4485-bb6a-c1db53606f45@github.com>

On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race <prr at openjdk.org> wrote:

> From a build perspective this partially reverts https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps 
> the harfbuzz sources separate and still supports building and running against a system harfbuzz which is only of interest or relevance on Linux.
> 
> I ended up having to go this way because its is the least unsatisfactory solution.
> I did not want us to build a devkit to link against a system linux only to find we couldn't use it at runtime
> because too many systems have to old a version of harfbuzz.
> 
> This solves the Manjaro Linux problem and I've manually verified building against a system hardbuxz on Ubuntu 20.10
> 
> There are couple of incidental fixes in here too
> - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building against a system version
> - harfbuzz/hb-ucdn is gone and should not be listed as a header directory needed to build the bundled copy
> - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502

This pull request has now been integrated.

Changeset: 05fe06a6
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/05fe06a6
Stats:     96 lines in 2 files changed: 7 ins; 51 del; 38 mod

8255790: GTKL&F: Java 16 crashes on initialising GTKL&F on Manjaro Linux

Reviewed-by: serb, ihse, azvegint

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

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

From serb at openjdk.java.net  Tue Mar 16 19:49:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 19:49:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <auyqIoUUeLpZr-pRga_n1W2p9W95MFQnfot_0Vj6Wyk=.28acfb50-62af-4670-b3a0-f77b181d3371@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
 <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>
 <RtpTWeSKgDVs0BKBbTrtGrWTzKLM2aW0_hUo0gni1-k=.952189ee-ffd6-4962-9541-d7c9888e9dbe@github.com>
 <9-0Gtuwqcg22dWmmXwr6eSOF_hSxEpA3J-F4Mc-rdYY=.12820f83-bf7e-453f-a262-da82c7001087@github.com>
 <auyqIoUUeLpZr-pRga_n1W2p9W95MFQnfot_0Vj6Wyk=.28acfb50-62af-4670-b3a0-f77b181d3371@github.com>
Message-ID: <sAYyXJEYkIeDbaeZRXhitz86cWfwOh_s4DWg1xEtSzo=.8db7168b-b905-4de1-a28a-dea635e29930@github.com>

On Tue, 16 Mar 2021 08:50:27 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

> What kind of test are you having in mind? I can extend the added MacEmoji.java test, that will check that 'something' is painted to different types of BufferedImage-s and/or with transforms applied. Or you want me to add a manual test case?

The automated tests will be enough, not sure about 'something is painted' however, it is better to check that it works.

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

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

From serb at openjdk.java.net  Tue Mar 16 21:44:27 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 21:44:27 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263622: The
 java.awt.color.ICC_Profile#setData invert the order of bytes for the "head"
 tag
Message-ID: <ZNXHazKkza89-Vm6FUvpWU5__mjKbZtn1_1n_W0Ffi4=.bf9b5748-06a3-4607-919d-7711e80feb53@github.com>

The root cause is using the wrong endian, the ICC profile uses big-endian notation. We even have special methods to convert the data, but for some reason, their usage was dropped in the JDK-6523398.

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

Commit messages:
 - test update
 - reformat
 - use built-in AdjustEndiannessXX
 - Initial version

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

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

From serb at openjdk.java.net  Tue Mar 16 21:44:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 21:44:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263622: The
 java.awt.color.ICC_Profile#setData invert the order of bytes for the "head"
 tag
In-Reply-To: <ZNXHazKkza89-Vm6FUvpWU5__mjKbZtn1_1n_W0Ffi4=.bf9b5748-06a3-4607-919d-7711e80feb53@github.com>
References: <ZNXHazKkza89-Vm6FUvpWU5__mjKbZtn1_1n_W0Ffi4=.bf9b5748-06a3-4607-919d-7711e80feb53@github.com>
Message-ID: <At-anO7OAef_H39dLZm0IKDKdgc3X3loHZue1oP1RXI=.8a52a927-9eca-413e-8509-ebac74f67e40@github.com>

On Tue, 16 Mar 2021 20:08:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The root cause is using the wrong endian, the ICC profile uses big-endian notation. We even have special methods to convert the data, but for some reason, their usage was dropped in the JDK-6523398.

src/java.desktop/share/native/liblcms/LCMS.c line 46:

> 44:                 ((int) SigMake ((a), (b), (c), (d)))
> 45: 
> 46: #define SigHead TagIdConst('h','e','a','d')

The logic of this method is the same as _cmsAdjustEndianess32 from the "lcms2_plugin.h"
https://github.com/openjdk/jdk/blob/9cb9af68659eaa60c9523c23a85ea37af57a5280/src/java.desktop/share/native/liblcms/cmsplugin.c#L87

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

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

From dbatrak at openjdk.java.net  Wed Mar 17 10:47:47 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Wed, 17 Mar 2021 10:47:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <sAYyXJEYkIeDbaeZRXhitz86cWfwOh_s4DWg1xEtSzo=.8db7168b-b905-4de1-a28a-dea635e29930@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
 <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>
 <RtpTWeSKgDVs0BKBbTrtGrWTzKLM2aW0_hUo0gni1-k=.952189ee-ffd6-4962-9541-d7c9888e9dbe@github.com>
 <9-0Gtuwqcg22dWmmXwr6eSOF_hSxEpA3J-F4Mc-rdYY=.12820f83-bf7e-453f-a262-da82c7001087@github.com>
 <auyqIoUUeLpZr-pRga_n1W2p9W95MFQnfot_0Vj6Wyk=.28acfb50-62af-4670-b3a0-f77b181d3371@github.com>
 <sAYyXJEYkIeDbaeZRXhitz86cWfwOh_s4DWg1xEtSzo=.8db7168b-b905-4de1-a28a-dea635e29930@github.com>
Message-ID: <V_6L9ypRBgiVfbqDX6geP-_r4UD9RFBLFcof6hmL7sw=.47b979af-7b8b-421b-978a-198ae6d0e46e@github.com>

On Tue, 16 Mar 2021 19:46:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> If it is a complete "General" loop which supports all possible combination of incoming src/comp/dst/transform/etc I suggest to confirm that in the test.
>> 
>> @mrserb This code is currently only used by GlyphListLoopPipe-based text renderers (SolidTextRenderer, AATextRenderer, LCDTextRenderer), so it won't be invoked for arbitrary composites and paint types. But different destination types (image formats) and transforms are supported.
>> 
>> What kind of test are you having in mind? I can extend the added MacEmoji.java test, that will check that 'something' is painted to different types of BufferedImage-s and/or with transforms applied. Or you want me to add a manual test case?
>
>> What kind of test are you having in mind? I can extend the added MacEmoji.java test, that will check that 'something' is painted to different types of BufferedImage-s and/or with transforms applied. Or you want me to add a manual test case?
> 
> The automated tests will be enough, not sure about 'something is painted' however, it is better to check that it works.

@mrserb I don't know how to check automatically that glyph painting works correctly. Could you please suggest a way to do it? In JetBrains Runtime we have a test that checks that rendered emoji glyph matches one of stored 'golden images', but I don't think that's suitable for OpenJDK, unless someone will volunteer to update that list when the need arises (e.g. when newer version of macOS changes the font, or rendering details). At the moment, we have already 7 golden images for a single glyph in our repository.

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

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

From azvegint at openjdk.java.net  Wed Mar 17 14:32:48 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 17 Mar 2021 14:32:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263622: The
 java.awt.color.ICC_Profile#setData invert the order of bytes for the "head"
 tag
In-Reply-To: <ZNXHazKkza89-Vm6FUvpWU5__mjKbZtn1_1n_W0Ffi4=.bf9b5748-06a3-4607-919d-7711e80feb53@github.com>
References: <ZNXHazKkza89-Vm6FUvpWU5__mjKbZtn1_1n_W0Ffi4=.bf9b5748-06a3-4607-919d-7711e80feb53@github.com>
Message-ID: <NEtARCqWGQSm0g8ddu7W2E5n9mjvHF5iO6jVqQ18V5g=.174c8799-3f79-4cab-b2ea-070fdaee24e5@github.com>

On Tue, 16 Mar 2021 20:08:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The root cause is using the wrong endian, the ICC profile uses big-endian notation. We even have special methods to convert the data, but for some reason, their usage was dropped in the JDK-6523398.

Marked as reviewed by azvegint (Reviewer).

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

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

From herrick at openjdk.java.net  Wed Mar 17 15:35:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 15:35:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
Message-ID: <4WfIqOQTCLxtbCQnD2xn4Doku9I1K5cnZ3FOv_JfeJQ=.09c24289-7e79-4592-9043-36b3b790701f@github.com>

On Sun, 14 Mar 2021 12:06:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> the

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

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

From herrick at openjdk.java.net  Wed Mar 17 15:35:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 15:35:49 GMT
Subject: [OpenJDK 2D-Dev] Withdrawn: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <HTWVY7MhXEo0XsFT0RVMz53wTcGRnOg8SwGNghVgDtk=.7c738703-a42a-4f3e-9466-df2cf05cf2d0@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

This pull request has been closed without being integrated.

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

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

From herrick at openjdk.java.net  Wed Mar 17 16:46:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 16:46:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
Message-ID: <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>

On Sun, 14 Mar 2021 12:06:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> 
> Have you looked at narrowing the use of the SuppressWarnings to local variable declarations to avoid adding it to some of these methods?

in all cases either:
 - the class or method itself is being deprecated
 - the method takes a deprecated arg .
 - there is no local variable involved, such as testing if something  is an instanceOf a class being deprecated, or calling a deprecated method.

I cannot find any instances where the scope can be narrowed

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

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

From alanb at openjdk.java.net  Wed Mar 17 19:05:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Mar 2021 19:05:52 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
Message-ID: <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>

On Wed, 17 Mar 2021 16:44:19 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> I cannot find any instances where the scope can be narrowed

Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?

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

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

From prr at openjdk.java.net  Wed Mar 17 19:31:00 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 17 Mar 2021 19:31:00 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263439: getSupportedAttributeValues() throws
 NPE for Finishings attribute
Message-ID: <glGstQmvAjthFvZd9Fup7KZUYVfcmam8Zq0OFX2MXkg=.9a5aee93-7fe1-495a-8796-f317e6fab32b@github.com>

This seems to be a code path that has has not been exercised.
We need to check for null values in the array.

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

Commit messages:
 - 8263439: getSupportedAttributeValues() throws NPE for Finishings attribute

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

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

From herrick at openjdk.java.net  Wed Mar 17 20:35:54 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 20:35:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
 <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
Message-ID: <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>

On Wed, 17 Mar 2021 19:02:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> 
> > I cannot find any instances where the scope can be narrowed
> 
> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?

These have the code pattern such as: 
} else if (c instanceof JApplet) {
putting '@SuppressWarnings("removal")' before the declaration of 'c' does not help, because the code is not an assignment to 'c'

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

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

From azvegint at openjdk.java.net  Wed Mar 17 20:46:54 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 17 Mar 2021 20:46:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263482: Make access to the ICC color
 profiles data multithread-friendly
In-Reply-To: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>
References: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>
Message-ID: <ohxuHVIgojgCPBdkGbjjfBxZZfnPGtlIp99foVcdoGo=.f8946e98-8c80-474c-a732-6f22a913a318@github.com>

On Fri, 12 Mar 2021 05:10:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> FYI: probably is better/simpler to review it via webrev.
> 
> After migration to the lcms from the kcms the performance of some operations was regressed. One possible workaround was to split the operation into multiple threads. But unfortunately, we have too many bottlenecks which prevent using multithreading. This is the request to remove/minimize such bottlenecks(at least some of them), but it does not affect the single-threaded performance it should be handled separately.
> 
> The main code pattern optimized here is this:
>     activate();
>     byte[] theHeader = getData(cmmProfile, icSigHead);
>     ---->  CMSManager.getModule().getTagData(p, tagSignature);
> Notes about the code above:
> 
> 1. Before the change "activate()" method checked that the "cmmProfile" field was not null. After that we usually used the "cmmProfile" as the parameter to some other method. This included two volatile reads, and also required to check when we need to call the "activate()" method before usage of the "cmmProfile" field.
> Solution: "activate()" renamed to the "cmmProfile()" which became an accessor for the field, so we will get one volatile read and can easily monitor the usage of the field itself(it is used directly only in this method).
> 
> 2. The synchronized static method "CMSManager.getModule()" reimplemented to have only one volatile read.
> 
> 3. The usage of locking in the "getTagData()" is changed. Instead of the synchronized instance methods, we now use the mix of "ConcurrentHashMap" and StampedLock.
> 
> See some comments inline.
> 
> Some numbers(small numbers are better):
> 
> 1. Performance of ((ICC_ProfileRGB) ICC_Profile.getInstance(ColorSpace.CS_sRGB)).getMatrix();
> 
> jdk 15.0.2
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   19,624 ?    0,059  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,154 ?    0,001  us/op
> 
> jdk - before the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   12,935 ?    0,042  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,127 ?    0,007  us/op
> 
> jdk - after the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5    0,561 ?    0,005  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,092 ?    0,001  us/op
> 
> 2. Part of performance gain in jdk17 is from some other fixes, for example
>     Performance of ICC_Profile.getInstance(ColorSpace.CS_sRGB); and ColorSpace.getInstance(ColorSpace.CS_sRGB);
> 
> jdk 15.0.2
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    2,299 ?    0,032  us/op
> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    2,210 ?    0,051  us/op
> CMMPerf.testGetSRGBProfile             avgt    5    0,019 ?    0,001  us/op
> CMMPerf.testGetSRGBSpace               avgt    5    0,018 ?    0,001  us/op
> 
> jdk - same before/ after the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    0,005 ?    0,001  us/op
> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    0,005 ?    0,001  us/op
> CMMPerf.testGetSRGBProfile             avgt    5    0,005 ?    0,001  us/op
> CMMPerf.testGetSRGBSpace               avgt    5    0,005 ?    0,001  us/op
> 
> note "ThreadsMAX" is 32 threads.

src/java.desktop/share/native/liblcms/LCMS.c line 644:

> 642:         return cmmProfile;
> 643:     }
> 644:     return NULL;

Why do we need to do this from native code? (except easing of access to a private method of a class in another package.)
Will it give some noticeable performance boost if we implement it on java side?

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

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

From serb at openjdk.java.net  Wed Mar 17 23:00:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 17 Mar 2021 23:00:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263482: Make access to the ICC color
 profiles data multithread-friendly
In-Reply-To: <ohxuHVIgojgCPBdkGbjjfBxZZfnPGtlIp99foVcdoGo=.f8946e98-8c80-474c-a732-6f22a913a318@github.com>
References: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>
 <ohxuHVIgojgCPBdkGbjjfBxZZfnPGtlIp99foVcdoGo=.f8946e98-8c80-474c-a732-6f22a913a318@github.com>
Message-ID: <fkwMN3s-qV5BUyLREt2xRwS3hw0-PWyxsi_0QaF8qc0=.420bf9dc-6817-41b1-a3d2-ab48a275cade@github.com>

On Wed, 17 Mar 2021 20:41:47 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> FYI: probably is better/simpler to review it via webrev.
>> 
>> After migration to the lcms from the kcms the performance of some operations was regressed. One possible workaround was to split the operation into multiple threads. But unfortunately, we have too many bottlenecks which prevent using multithreading. This is the request to remove/minimize such bottlenecks(at least some of them), but it does not affect the single-threaded performance it should be handled separately.
>> 
>> The main code pattern optimized here is this:
>>     activate();
>>     byte[] theHeader = getData(cmmProfile, icSigHead);
>>     ---->  CMSManager.getModule().getTagData(p, tagSignature);
>> Notes about the code above:
>> 
>> 1. Before the change "activate()" method checked that the "cmmProfile" field was not null. After that we usually used the "cmmProfile" as the parameter to some other method. This included two volatile reads, and also required to check when we need to call the "activate()" method before usage of the "cmmProfile" field.
>> Solution: "activate()" renamed to the "cmmProfile()" which became an accessor for the field, so we will get one volatile read and can easily monitor the usage of the field itself(it is used directly only in this method).
>> 
>> 2. The synchronized static method "CMSManager.getModule()" reimplemented to have only one volatile read.
>> 
>> 3. The usage of locking in the "getTagData()" is changed. Instead of the synchronized instance methods, we now use the mix of "ConcurrentHashMap" and StampedLock.
>> 
>> See some comments inline.
>> 
>> Some numbers(small numbers are better):
>> 
>> 1. Performance of ((ICC_ProfileRGB) ICC_Profile.getInstance(ColorSpace.CS_sRGB)).getMatrix();
>> 
>> jdk 15.0.2
>> Benchmark                              Mode  Cnt    Score      Error  Units
>> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   19,624 ?    0,059  us/op
>> CMMPerf.testGetMatrix                  avgt    5    0,154 ?    0,001  us/op
>> 
>> jdk - before the fix
>> Benchmark                              Mode  Cnt    Score      Error  Units
>> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   12,935 ?    0,042  us/op
>> CMMPerf.testGetMatrix                  avgt    5    0,127 ?    0,007  us/op
>> 
>> jdk - after the fix
>> Benchmark                              Mode  Cnt    Score      Error  Units
>> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5    0,561 ?    0,005  us/op
>> CMMPerf.testGetMatrix                  avgt    5    0,092 ?    0,001  us/op
>> 
>> 2. Part of performance gain in jdk17 is from some other fixes, for example
>>     Performance of ICC_Profile.getInstance(ColorSpace.CS_sRGB); and ColorSpace.getInstance(ColorSpace.CS_sRGB);
>> 
>> jdk 15.0.2
>> Benchmark                              Mode  Cnt    Score      Error  Units
>> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    2,299 ?    0,032  us/op
>> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    2,210 ?    0,051  us/op
>> CMMPerf.testGetSRGBProfile             avgt    5    0,019 ?    0,001  us/op
>> CMMPerf.testGetSRGBSpace               avgt    5    0,018 ?    0,001  us/op
>> 
>> jdk - same before/ after the fix
>> Benchmark                              Mode  Cnt    Score      Error  Units
>> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    0,005 ?    0,001  us/op
>> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    0,005 ?    0,001  us/op
>> CMMPerf.testGetSRGBProfile             avgt    5    0,005 ?    0,001  us/op
>> CMMPerf.testGetSRGBSpace               avgt    5    0,005 ?    0,001  us/op
>> 
>> note "ThreadsMAX" is 32 threads.
>
> src/java.desktop/share/native/liblcms/LCMS.c line 644:
> 
>> 642:         return cmmProfile;
>> 643:     }
>> 644:     return NULL;
> 
> Why do we need to do this from native code? (except easing of access to a private method of a class in another package.)
> Will it give some noticeable performance boost if we implement it on java side?

Yes, this is the only reason.
I have a todo to check what access will be better, AWTAccessor/methodhandle/reflection vs jni.

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

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

From azvegint at openjdk.java.net  Wed Mar 17 23:39:47 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 17 Mar 2021 23:39:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263482: Make access to the ICC color
 profiles data multithread-friendly
In-Reply-To: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>
References: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>
Message-ID: <M-kOxUBqisx6PCWK52JFatFKZs3_zVGlKUHXzDIXlg0=.2f40eb78-4ecd-4ffd-b60c-59a0d89dec62@github.com>

On Fri, 12 Mar 2021 05:10:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> FYI: probably is better/simpler to review it via webrev.
> 
> After migration to the lcms from the kcms the performance of some operations was regressed. One possible workaround was to split the operation into multiple threads. But unfortunately, we have too many bottlenecks which prevent using multithreading. This is the request to remove/minimize such bottlenecks(at least some of them), but it does not affect the single-threaded performance it should be handled separately.
> 
> The main code pattern optimized here is this:
>     activate();
>     byte[] theHeader = getData(cmmProfile, icSigHead);
>     ---->  CMSManager.getModule().getTagData(p, tagSignature);
> Notes about the code above:
> 
> 1. Before the change "activate()" method checked that the "cmmProfile" field was not null. After that we usually used the "cmmProfile" as the parameter to some other method. This included two volatile reads, and also required to check when we need to call the "activate()" method before usage of the "cmmProfile" field.
> Solution: "activate()" renamed to the "cmmProfile()" which became an accessor for the field, so we will get one volatile read and can easily monitor the usage of the field itself(it is used directly only in this method).
> 
> 2. The synchronized static method "CMSManager.getModule()" reimplemented to have only one volatile read.
> 
> 3. The usage of locking in the "getTagData()" is changed. Instead of the synchronized instance methods, we now use the mix of "ConcurrentHashMap" and StampedLock.
> 
> See some comments inline.
> 
> Some numbers(small numbers are better):
> 
> 1. Performance of ((ICC_ProfileRGB) ICC_Profile.getInstance(ColorSpace.CS_sRGB)).getMatrix();
> 
> jdk 15.0.2
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   19,624 ?    0,059  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,154 ?    0,001  us/op
> 
> jdk - before the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   12,935 ?    0,042  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,127 ?    0,007  us/op
> 
> jdk - after the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5    0,561 ?    0,005  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,092 ?    0,001  us/op
> 
> 2. Part of performance gain in jdk17 is from some other fixes, for example
>     Performance of ICC_Profile.getInstance(ColorSpace.CS_sRGB); and ColorSpace.getInstance(ColorSpace.CS_sRGB);
> 
> jdk 15.0.2
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    2,299 ?    0,032  us/op
> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    2,210 ?    0,051  us/op
> CMMPerf.testGetSRGBProfile             avgt    5    0,019 ?    0,001  us/op
> CMMPerf.testGetSRGBSpace               avgt    5    0,018 ?    0,001  us/op
> 
> jdk - same before/ after the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    0,005 ?    0,001  us/op
> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    0,005 ?    0,001  us/op
> CMMPerf.testGetSRGBProfile             avgt    5    0,005 ?    0,001  us/op
> CMMPerf.testGetSRGBSpace               avgt    5    0,005 ?    0,001  us/op
> 
> note "ThreadsMAX" is 32 threads.

Marked as reviewed by azvegint (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Thu Mar 18 05:08:47 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 18 Mar 2021 05:08:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263439: getSupportedAttributeValues()
 throws NPE for Finishings attribute
In-Reply-To: <glGstQmvAjthFvZd9Fup7KZUYVfcmam8Zq0OFX2MXkg=.9a5aee93-7fe1-495a-8796-f317e6fab32b@github.com>
References: <glGstQmvAjthFvZd9Fup7KZUYVfcmam8Zq0OFX2MXkg=.9a5aee93-7fe1-495a-8796-f317e6fab32b@github.com>
Message-ID: <xSNYPJM5xyh47LFYA5qcQF2U7HMrCkGpvOLyHLNSphw=.915565f1-6cac-4fa5-81ff-36dafad79f4a@github.com>

On Wed, 17 Mar 2021 19:25:50 GMT, Phil Race <prr at openjdk.org> wrote:

> This seems to be a code path that has has not been exercised.
> We need to check for null values in the array.

Marked as reviewed by psadhukhan (Reviewer).

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

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

From serb at openjdk.java.net  Thu Mar 18 10:04:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 18 Mar 2021 10:04:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <V_6L9ypRBgiVfbqDX6geP-_r4UD9RFBLFcof6hmL7sw=.47b979af-7b8b-421b-978a-198ae6d0e46e@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
 <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>
 <RtpTWeSKgDVs0BKBbTrtGrWTzKLM2aW0_hUo0gni1-k=.952189ee-ffd6-4962-9541-d7c9888e9dbe@github.com>
 <9-0Gtuwqcg22dWmmXwr6eSOF_hSxEpA3J-F4Mc-rdYY=.12820f83-bf7e-453f-a262-da82c7001087@github.com>
 <auyqIoUUeLpZr-pRga_n1W2p9W95MFQnfot_0Vj6Wyk=.28acfb50-62af-4670-b3a0-f77b181d3371@github.com>
 <sAYyXJEYkIeDbaeZRXhitz86cWfwOh_s4DWg1xEtSzo=.8db7168b-b905-4de1-a28a-dea635e29930@github.com>
 <V_6L9ypRBgiVfbqDX6geP-_r4UD9RFBLFcof6hmL7sw=.47b979af-7b8b-421b-978a-198ae6d0e46e@github.com>
Message-ID: <CTYqY1qg3m1Umd5uxTcTMSuMdVm9krDstxAxJ-dn3qs=.77819b22-00df-49f9-95fa-aa1f7e04e2eb@github.com>

On Wed, 17 Mar 2021 10:45:00 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>>> What kind of test are you having in mind? I can extend the added MacEmoji.java test, that will check that 'something' is painted to different types of BufferedImage-s and/or with transforms applied. Or you want me to add a manual test case?
>> 
>> The automated tests will be enough, not sure about 'something is painted' however, it is better to check that it works.
>
> @mrserb I don't know how to check automatically that glyph painting works correctly. Could you please suggest a way to do it? In JetBrains Runtime we have a test that checks that rendered emoji glyph matches one of stored 'golden images', but I don't think that's suitable for OpenJDK, unless someone will volunteer to update that list when the need arises (e.g. when newer version of macOS changes the font, or rendering details). At the moment, we have already 7 golden images for a single glyph in our repository.

You the current image from the MacEmoji test as a golden image for other formats/transforms/extraalpha/etc. For example, if DST type is changed then it is unlikely the shape of the emoji will be changed as well, or if it is too big/ too small.

BTW It will be good if the test will fail on the current metal implementation.

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

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

From alexsch at openjdk.java.net  Thu Mar 18 12:29:01 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Thu, 18 Mar 2021 12:29:01 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with
 low DPI has bad quality on Windows [v2]
In-Reply-To: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
References: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
Message-ID: <Pv-3othcHkeCmAzzT4N-Yo6PgpSZDvWKpTAv64eMrlg=.db259733-c420-4ff7-8a66-284ce87994c0@github.com>

> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
> The GDI system used for text printing on Windows accepts only integer path coordinates.
> Rounding GlyphVector outline coordinates leads to distorted printed text.
> 
> The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page".
> 
> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
> 
> The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
> 
> I tried to put wPrinterJob.beginPath()/endPath()  methods around wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape.
> 
> The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method.
> The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() .
> 
> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix.
> 
> There are two failed automated tests which fail without the fix as well:
> java/awt/print/PrinterJob/GlyphPositions.java 
> java/awt/print/PrinterJob/PSQuestionMark.java
> 
> The following manual tests have issues on my system:
> - `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static"
> 
> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons.
> 
> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
> 
> 
> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain  print/pass/fail buttons and it is not possible to close the window.
> 
> - The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message:
> java/awt/print/Dialog/DialogOrient.java
> java/awt/print/Dialog/DialogType.java
> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
> java/awt/print/PrinterJob/PageDialogTest.java
> java/awt/print/PrinterJob/PageRanges.java
> java/awt/print/PrinterJob/PageRangesDlgTest.java
> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
> java/awt/print/PrinterJob/PrintLatinCJKTest.java
> java/awt/print/PrinterJob/PrintTextTest.java
> java/awt/print/PrinterJob/SwingUIText.java
> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
> java/awt/PrintJob/SaveDialogTitleTest.java

Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:

 - Use DASSERT to check SetGraphicsMode and WorldTransform results
 - Change setGraphicsMode() type to void

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2756/files
  - new: https://git.openjdk.java.net/jdk/pull/2756/files/e0278acd..8105885f

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

  Stats: 21 lines in 2 files changed: 8 ins; 2 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2756.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2756/head:pull/2756

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

From alexsch at openjdk.java.net  Thu Mar 18 12:29:02 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Thu, 18 Mar 2021 12:29:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with
 low DPI has bad quality on Windows [v2]
In-Reply-To: <z-ZS7TWcjnioODkkg2P4xCrXeFCvueuwbBKf6dsNT0E=.f7c9006e-5712-4d7c-9038-9c195affcae6@github.com>
References: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
 <z-ZS7TWcjnioODkkg2P4xCrXeFCvueuwbBKf6dsNT0E=.f7c9006e-5712-4d7c-9038-9c195affcae6@github.com>
Message-ID: <In7GC0jWgg6gHmP_FBzcdwNkLbwQQKJfMH4qcAVBLCE=.33beda07-f54b-46b8-9d9b-c6ee87419651@github.com>

On Wed, 10 Mar 2021 09:31:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use DASSERT to check SetGraphicsMode and WorldTransform results
>>  - Change setGraphicsMode() type to void
>
> src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1025:
> 
>> 1023:      * {@code GM_COMPATIBLE} or {@code GM_ADVANCED}.
>> 1024:      */
>> 1025:     private int setGraphicsMode(int mode) {
> 
> Is there any need of "int" return value? I dont see it is used in restoreTransform()

I updated the code to return void from setGraphicsMode() method.

> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 2033:
> 
>> 2031:     xForm.eDy  = (FLOAT) elems[5];
>> 2032: 
>> 2033:     ::SetWorldTransform((HDC)printDC, &xForm);
> 
> Probably we should check for the return value of all this system APIs SetGraphicsMode, GetWorldTransform, SetWorldTransform, ModifyWorldTransform to see if it succeeded?

I added DASSERT to check SetGraphicsMode and Get/Set/ModifyWorldTransform results.

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

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

From aivanov at openjdk.java.net  Thu Mar 18 13:29:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 18 Mar 2021 13:29:42 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263311: Watch registry changes for
 remote printers update instead of polling
In-Reply-To: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
References: <GuMrsp8Go4joy-Xnu5hye5ifomX7IR9zbDqKvDxxEOc=.fa91ed3e-612a-4591-a300-5b6e9c178421@github.com>
Message-ID: <3uCeqTMz_Wpfdgn4c08Os6yCFLR5fSYwtearX8_WnYE=.840861ee-07a9-496c-b066-8b3fabc7df4b@github.com>

On Wed, 10 Mar 2021 15:38:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8153732](https://bugs.openjdk.java.net/browse/JDK-8153732) implemented polling for remote printers.
> That bug description also mentions watching the registry for changes and links to the article which describes the method yet it does so in terms of WMI. Using WMI is not necessary to watch for the registry updates.
> 
> It is possible to replace polling mechanism with registry change notifications. If the registry at `HKCU\Printers\Connections` is updated, refresh the list of print services.
> 
> It works perfectly well in my own testing with sharing a Generic / Text Only printer from another laptop. The notification comes as soon as the printer is installed, it results in a new key created under `Connections`. If a remote printer is removed, the notification is also triggered as the key corresponding to that printer is removed from the registry.
> 
> I updated the steps in the manual test: `RemotePrinterStatusRefresh.java`.

This pull request has now been integrated.

Changeset: a85dc557
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a85dc557
Stats:     207 lines in 3 files changed: 31 ins; 158 del; 18 mod

8263311: Watch registry changes for remote printers update instead of polling

Reviewed-by: psadhukhan, serb

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

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

From prr at openjdk.java.net  Thu Mar 18 17:30:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 18 Mar 2021 17:30:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263439: getSupportedAttributeValues()
 throws NPE for Finishings attribute [v2]
In-Reply-To: <glGstQmvAjthFvZd9Fup7KZUYVfcmam8Zq0OFX2MXkg=.9a5aee93-7fe1-495a-8796-f317e6fab32b@github.com>
References: <glGstQmvAjthFvZd9Fup7KZUYVfcmam8Zq0OFX2MXkg=.9a5aee93-7fe1-495a-8796-f317e6fab32b@github.com>
Message-ID: <1-e7kW75Cs3zGnL9ocVpcQRJ6p-GlNzWyDUwWNB-QQo=.da13a37d-bc7a-46eb-a3d5-1f9881b02624@github.com>

> This seems to be a code path that has has not been exercised.
> We need to check for null values in the array.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8263439: getSupportedAttributeValues() throws NPE for Finishings attribute

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3055/files
  - new: https://git.openjdk.java.net/jdk/pull/3055/files/c7b30e53..f333515f

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

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

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

From azvegint at openjdk.java.net  Thu Mar 18 18:44:40 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 18 Mar 2021 18:44:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263439: getSupportedAttributeValues()
 throws NPE for Finishings attribute [v2]
In-Reply-To: <1-e7kW75Cs3zGnL9ocVpcQRJ6p-GlNzWyDUwWNB-QQo=.da13a37d-bc7a-46eb-a3d5-1f9881b02624@github.com>
References: <glGstQmvAjthFvZd9Fup7KZUYVfcmam8Zq0OFX2MXkg=.9a5aee93-7fe1-495a-8796-f317e6fab32b@github.com>
 <1-e7kW75Cs3zGnL9ocVpcQRJ6p-GlNzWyDUwWNB-QQo=.da13a37d-bc7a-46eb-a3d5-1f9881b02624@github.com>
Message-ID: <HlQQfL-Y-faXlDv9rGuQh_nmAU514p8kIL2pMScLHDE=.01e353a2-d557-4430-ae9b-c8fa181f8bd8@github.com>

On Thu, 18 Mar 2021 17:30:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> This seems to be a code path that has has not been exercised.
>> We need to check for null values in the array.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263439: getSupportedAttributeValues() throws NPE for Finishings attribute

Marked as reviewed by azvegint (Reviewer).

src/java.desktop/unix/classes/sun/print/IPPPrintService.java line 572:

> 570:                             (new ExtFinishing(100)).getAll();
> 571:                         for (int j=0; j<fAll.length; j++) {
> 572:                             if (fAll[j] == null) {

Are we still insisting on copyright's year update?

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

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

From prr at openjdk.java.net  Thu Mar 18 20:03:40 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 18 Mar 2021 20:03:40 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263439: getSupportedAttributeValues()
 throws NPE for Finishings attribute
In-Reply-To: <glGstQmvAjthFvZd9Fup7KZUYVfcmam8Zq0OFX2MXkg=.9a5aee93-7fe1-495a-8796-f317e6fab32b@github.com>
References: <glGstQmvAjthFvZd9Fup7KZUYVfcmam8Zq0OFX2MXkg=.9a5aee93-7fe1-495a-8796-f317e6fab32b@github.com>
Message-ID: <aeC1v8Nd-xjvhvvIRVLFmwkDZfkRvy5cGLTvPi0_jO8=.44d24a4c-fba3-4f6a-aa4e-6e05dfb55df7@github.com>

On Wed, 17 Mar 2021 19:25:50 GMT, Phil Race <prr at openjdk.org> wrote:

> This seems to be a code path that has has not been exercised.
> We need to check for null values in the array.

This pull request has now been integrated.

Changeset: 2173fedd
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2173fedd
Stats:     67 lines in 2 files changed: 67 ins; 0 del; 0 mod

8263439: getSupportedAttributeValues() throws NPE for Finishings attribute

Reviewed-by: psadhukhan, azvegint

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

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

From serb at openjdk.java.net  Thu Mar 18 20:10:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 18 Mar 2021 20:10:40 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263622: The
 java.awt.color.ICC_Profile#setData invert the order of bytes for the "head"
 tag
In-Reply-To: <ZNXHazKkza89-Vm6FUvpWU5__mjKbZtn1_1n_W0Ffi4=.bf9b5748-06a3-4607-919d-7711e80feb53@github.com>
References: <ZNXHazKkza89-Vm6FUvpWU5__mjKbZtn1_1n_W0Ffi4=.bf9b5748-06a3-4607-919d-7711e80feb53@github.com>
Message-ID: <_L4Clr30gcmjdLjCxg6eW6OeR6Bahg6iN9rwCy5HNWw=.941fa68e-a377-4b1b-9cec-df2a4bfa5810@github.com>

On Tue, 16 Mar 2021 20:08:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The root cause is using the wrong endian, the ICC profile uses big-endian notation. We even have special methods to convert the data, but for some reason, their usage was dropped in the JDK-6523398.

This pull request has now been integrated.

Changeset: 01ddf3d2
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/01ddf3d2
Stats:     132 lines in 2 files changed: 88 ins; 35 del; 9 mod

8263622: The java.awt.color.ICC_Profile#setData invert the order of bytes for the "head" tag

Reviewed-by: azvegint

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

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

From prr at openjdk.java.net  Thu Mar 18 21:00:50 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 18 Mar 2021 21:00:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263833: Stop disabling warnings for
 sunFont.c with gcc
Message-ID: <rdgWINpDk-P2QhJfu6-Oo2Qh_NOEhI1_DqYYfwVKRpA=.457563e7-f609-4bb4-afb9-dfa2c92ef9f3@github.com>

As per the bug report the code that was the reason for disabling warnings on this file was removed in November 2019
as part of https://bugs.openjdk.java.net/browse/JDK-8220231 so we can get rid of the need to disable warnings.

Longer history in the bug report.

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

Commit messages:
 - 8263833: Stop disabling warnings for sunFont.c with gcc

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

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

From erikj at openjdk.java.net  Thu Mar 18 21:47:39 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 18 Mar 2021 21:47:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263833: Stop disabling warnings for
 sunFont.c with gcc
In-Reply-To: <rdgWINpDk-P2QhJfu6-Oo2Qh_NOEhI1_DqYYfwVKRpA=.457563e7-f609-4bb4-afb9-dfa2c92ef9f3@github.com>
References: <rdgWINpDk-P2QhJfu6-Oo2Qh_NOEhI1_DqYYfwVKRpA=.457563e7-f609-4bb4-afb9-dfa2c92ef9f3@github.com>
Message-ID: <W2cb1Qo9ON9I8DKb438JiT5PdaXhBgFdxb6XIvczj40=.1588fd0b-7a74-42cd-b4c9-a4d509f3d5b2@github.com>

On Thu, 18 Mar 2021 20:54:27 GMT, Phil Race <prr at openjdk.org> wrote:

> As per the bug report the code that was the reason for disabling warnings on this file was removed in November 2019
> as part of https://bugs.openjdk.java.net/browse/JDK-8220231 so we can get rid of the need to disable warnings.
> 
> Longer history in the bug report.

Marked as reviewed by erikj (Reviewer).

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

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

From prr at openjdk.java.net  Thu Mar 18 21:55:39 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 18 Mar 2021 21:55:39 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263833: Stop disabling warnings for
 sunFont.c with gcc
In-Reply-To: <rdgWINpDk-P2QhJfu6-Oo2Qh_NOEhI1_DqYYfwVKRpA=.457563e7-f609-4bb4-afb9-dfa2c92ef9f3@github.com>
References: <rdgWINpDk-P2QhJfu6-Oo2Qh_NOEhI1_DqYYfwVKRpA=.457563e7-f609-4bb4-afb9-dfa2c92ef9f3@github.com>
Message-ID: <qba7eeI_6ZyzleuM16Gqubxow5wREAfNGBzjYnku4Dg=.070a5616-fbfa-4786-baf7-c38fdf404548@github.com>

On Thu, 18 Mar 2021 20:54:27 GMT, Phil Race <prr at openjdk.org> wrote:

> As per the bug report the code that was the reason for disabling warnings on this file was removed in November 2019
> as part of https://bugs.openjdk.java.net/browse/JDK-8220231 so we can get rid of the need to disable warnings.
> 
> Longer history in the bug report.

This pull request has now been integrated.

Changeset: ed1e25d5
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed1e25d5
Stats:     6 lines in 1 file changed: 0 ins; 6 del; 0 mod

8263833: Stop disabling warnings for sunFont.c with gcc

Reviewed-by: erikj

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

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

From prr at openjdk.java.net  Thu Mar 18 23:05:46 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 18 Mar 2021 23:05:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8247370: Clean up unused printing code in
 awt_PrintJob.cpp
Message-ID: <91SED6lpn5sTusWtKDpsfECjI4PBPGAe3CdF9uYRsgk=.93533363-2e60-4172-8a41-f62c3df0ec83@github.com>

This removes a long time un-used code path.

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

Commit messages:
 - 8247370: Clean up unused printing code in awt_PrintJob.cpp

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

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

From serb at openjdk.java.net  Fri Mar 19 02:51:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Mar 2021 02:51:38 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263482: Make access to the ICC color
 profiles data multithread-friendly
In-Reply-To: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>
References: <TRGuHD9xohDssYOZJiBnBYmHA8f-4NQgpM8ZLWNy8yY=.2da6c249-1df8-48c2-9471-66a91aba6c0f@github.com>
Message-ID: <3NHsCVboGu1I1PCtY4_FIX5mV-UFs5gDS7XpkqHVb3c=.ce65ca97-7c6b-4918-91e5-6b6be3dfdfda@github.com>

On Fri, 12 Mar 2021 05:10:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> FYI: probably is better/simpler to review it via webrev.
> 
> After migration to the lcms from the kcms the performance of some operations was regressed. One possible workaround was to split the operation into multiple threads. But unfortunately, we have too many bottlenecks which prevent using multithreading. This is the request to remove/minimize such bottlenecks(at least some of them), but it does not affect the single-threaded performance it should be handled separately.
> 
> The main code pattern optimized here is this:
>     activate();
>     byte[] theHeader = getData(cmmProfile, icSigHead);
>     ---->  CMSManager.getModule().getTagData(p, tagSignature);
> Notes about the code above:
> 
> 1. Before the change "activate()" method checked that the "cmmProfile" field was not null. After that we usually used the "cmmProfile" as the parameter to some other method. This included two volatile reads, and also required to check when we need to call the "activate()" method before usage of the "cmmProfile" field.
> Solution: "activate()" renamed to the "cmmProfile()" which became an accessor for the field, so we will get one volatile read and can easily monitor the usage of the field itself(it is used directly only in this method).
> 
> 2. The synchronized static method "CMSManager.getModule()" reimplemented to have only one volatile read.
> 
> 3. The usage of locking in the "getTagData()" is changed. Instead of the synchronized instance methods, we now use the mix of "ConcurrentHashMap" and StampedLock.
> 
> See some comments inline.
> 
> Some numbers(small numbers are better):
> 
> 1. Performance of ((ICC_ProfileRGB) ICC_Profile.getInstance(ColorSpace.CS_sRGB)).getMatrix();
> 
> jdk 15.0.2
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   19,624 ?    0,059  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,154 ?    0,001  us/op
> 
> jdk - before the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5   12,935 ?    0,042  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,127 ?    0,007  us/op
> 
> jdk - after the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetMatrix       avgt    5    0,561 ?    0,005  us/op
> CMMPerf.testGetMatrix                  avgt    5    0,092 ?    0,001  us/op
> 
> 2. Part of performance gain in jdk17 is from some other fixes, for example
>     Performance of ICC_Profile.getInstance(ColorSpace.CS_sRGB); and ColorSpace.getInstance(ColorSpace.CS_sRGB);
> 
> jdk 15.0.2
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    2,299 ?    0,032  us/op
> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    2,210 ?    0,051  us/op
> CMMPerf.testGetSRGBProfile             avgt    5    0,019 ?    0,001  us/op
> CMMPerf.testGetSRGBSpace               avgt    5    0,018 ?    0,001  us/op
> 
> jdk - same before/ after the fix
> Benchmark                              Mode  Cnt    Score      Error  Units
> CMMPerf.ThreadsMAX.testGetSRGBProfile  avgt    5    0,005 ?    0,001  us/op
> CMMPerf.ThreadsMAX.testGetSRGBSpace    avgt    5    0,005 ?    0,001  us/op
> CMMPerf.testGetSRGBProfile             avgt    5    0,005 ?    0,001  us/op
> CMMPerf.testGetSRGBSpace               avgt    5    0,005 ?    0,001  us/op
> 
> note "ThreadsMAX" is 32 threads.

This pull request has now been integrated.

Changeset: 1a21f779
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1a21f779
Stats:     212 lines in 5 files changed: 52 ins; 83 del; 77 mod

8263482: Make access to the ICC color profiles data multithread-friendly

Reviewed-by: azvegint

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

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

From serb at openjdk.java.net  Fri Mar 19 03:01:39 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Mar 2021 03:01:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8247370: Clean up unused printing code in
 awt_PrintJob.cpp
In-Reply-To: <91SED6lpn5sTusWtKDpsfECjI4PBPGAe3CdF9uYRsgk=.93533363-2e60-4172-8a41-f62c3df0ec83@github.com>
References: <91SED6lpn5sTusWtKDpsfECjI4PBPGAe3CdF9uYRsgk=.93533363-2e60-4172-8a41-f62c3df0ec83@github.com>
Message-ID: <VpkBH1tKxRb6ZVavVj76WWS1YlIj9QRZ_Zt_Cvu2vP0=.b35d6541-6edb-4bd6-acb6-e4ec8e9c3361@github.com>

On Thu, 18 Mar 2021 22:59:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes a long time un-used code path.

Marked as reviewed by serb (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Fri Mar 19 04:48:38 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 19 Mar 2021 04:48:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8247370: Clean up unused printing code in
 awt_PrintJob.cpp
In-Reply-To: <91SED6lpn5sTusWtKDpsfECjI4PBPGAe3CdF9uYRsgk=.93533363-2e60-4172-8a41-f62c3df0ec83@github.com>
References: <91SED6lpn5sTusWtKDpsfECjI4PBPGAe3CdF9uYRsgk=.93533363-2e60-4172-8a41-f62c3df0ec83@github.com>
Message-ID: <mqjtHvDG1Sy0iWKqM6kKdaYlRJdx4TJB_eM9_IQ2lTo=.187ee3e4-ecce-4335-8848-c00b7b9d8ef4@github.com>

On Thu, 18 Mar 2021 22:59:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes a long time un-used code path.

Maybe we should put noreg-cleanup in JBS.

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

Marked as reviewed by psadhukhan (Reviewer).

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

From aghaisas at openjdk.java.net  Fri Mar 19 10:22:48 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 19 Mar 2021 10:22:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263488: Verify CWarningWindow works with
 metal rendering pipeline
Message-ID: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>

Root cause : 
CWarningWindow creates a MTLLayer with null peer.
In MTLLayer.replaceSurfaceData() method, insets should be set only if peer is not null.

Fix : 
Added the required null check.

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

Commit messages:
 - set native insets only if peer is not null

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

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

From dbatrak at openjdk.java.net  Fri Mar 19 13:48:12 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Fri, 19 Mar 2021 13:48:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS [v2]
In-Reply-To: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
Message-ID: <3q5Im_Hh45tOK9VTt5A2nrRxvgHFB_j3wfsBQlq_jgg=.5ec0eced-845e-4883-bc08-539209ece792@github.com>

> This is the implementation used by JetBrains Runtime for the last 4 years, after some cleanup, and with one problem,
> found while preparing the pull request, fixed.
> Even though typical scenarios for a UI application should be covered, it's not a complete solution. In particular, emoji-s
> still won't be rendered for large font sizes (more than 100pt), and for non-trivial composite/painting modes.
> Notable implementation details are listed below.
> 
> **Glyph image generation**
> 
> Deprecated CGContextShowGlyphsAtPoint function, used by JDK on macOS to render text, cannot render emojis,
> CTFontDrawGlyphs is used instead. It ignores the scale component of text transformation matrix, so a 'real-sized'
> CTFont object should be passed to it. The same sizing procedure is done when calculating glyph metrics, because they
> are not scaled proportionally with font size (as they do for vector fonts).
> 
> **Glyph image storage**
> 
> Existing GlyphInfo structure is used to store color glyph image. Color glyph can be distinguished by having 4 bytes
> of storage per pixel. Color components are stored in pre-multiplied alpha format.
> 
> **Glyph rendering**
> 
> Previously, GlyphList instance always contained glyphs in the same format (solid, grayscale or LCD), determined by the
> effective rendering hint. Now the renderers must be prepared to GlyphList having 'normal' glyphs interspersed with
> color glyphs (they can appear due to font fallback). This isn't a problem for OpenGL renderer (used for on-screen painting),
> but GlyphListLoopPipe-based renderers (used for off-screen painting) needed an adjustment to be able to operate on
> specific segments of GlyphList.
> As an incidental optimization, calculation of GlyphList bounds ('getBounds' method) is performed now only when needed
> (most text renderers don't need this information).
> Speaking of the actual rendering of the glyph image, it's done by the straightforward glDrawPixels call in OpenGL renderer,
> and by re-using existing Blit primitive in off-screen renderers.
> 
> **Testing**
> 
> There's no good way to test the new functionality automatically, but I've added a test verifying that 'something' is
> rendered for the emoji character, when painting to BufferedImage.
> 
> Existing tests pass after the change.

Dmitry Batrak has updated the pull request incrementally with two additional commits since the last revision:

 - 8263583: Emoji rendering on macOS
   
   extended test case to cover different types of target surfaces
 - 8263583: Emoji rendering on macOS
   
   implementation for Metal rendering pipeline

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3007/files
  - new: https://git.openjdk.java.net/jdk/pull/3007/files/3865b397..a9b2e9c3

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

  Stats: 132 lines in 2 files changed: 118 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3007.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3007/head:pull/3007

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

From dbatrak at openjdk.java.net  Fri Mar 19 13:57:37 2021
From: dbatrak at openjdk.java.net (Dmitry Batrak)
Date: Fri, 19 Mar 2021 13:57:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <CTYqY1qg3m1Umd5uxTcTMSuMdVm9krDstxAxJ-dn3qs=.77819b22-00df-49f9-95fa-aa1f7e04e2eb@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
 <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>
 <RtpTWeSKgDVs0BKBbTrtGrWTzKLM2aW0_hUo0gni1-k=.952189ee-ffd6-4962-9541-d7c9888e9dbe@github.com>
 <9-0Gtuwqcg22dWmmXwr6eSOF_hSxEpA3J-F4Mc-rdYY=.12820f83-bf7e-453f-a262-da82c7001087@github.com>
 <auyqIoUUeLpZr-pRga_n1W2p9W95MFQnfot_0Vj6Wyk=.28acfb50-62af-4670-b3a0-f77b181d3371@github.com>
 <sAYyXJEYkIeDbaeZRXhitz86cWfwOh_s4DWg1xEtSzo=.8db7168b-b905-4de1-a28a-dea635e29930@github.com>
 <V_6L9ypRBgiVfbqDX6geP-_r4UD9RFBLFcof6hmL7sw=.47b979af-7b8b-421b-978a-198ae6d0e46e@github.com>
 <CTYqY1qg3m1Umd5uxTcTMSuMdVm9krDstxAxJ-dn3qs=.77819b22-00df-49f9-95fa-aa1f7e04e2eb@github.com>
Message-ID: <KyIYKTNRgKBhP6VGRnmY3Jdpw8x2YGBzWe7uKgSisXE=.fd9aa403-c3cc-4a1c-8cad-3fb93bfdb85a@github.com>

On Thu, 18 Mar 2021 10:02:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @mrserb I don't know how to check automatically that glyph painting works correctly. Could you please suggest a way to do it? In JetBrains Runtime we have a test that checks that rendered emoji glyph matches one of stored 'golden images', but I don't think that's suitable for OpenJDK, unless someone will volunteer to update that list when the need arises (e.g. when newer version of macOS changes the font, or rendering details). At the moment, we have already 7 golden images for a single glyph in our repository.
>
> You the current image from the MacEmoji test as a golden image for other formats/transforms/extraalpha/etc. For example, if DST type is changed then it is unlikely the shape of the emoji will be changed as well, or if it is too big/ too small.
> 
> BTW It will be good if the test will fail on the current metal implementation.

Implementation for Metal pipeline has been added.

I've also updated the test case to check rendering into different types of images, including VolatileImage. The test will fail now, if corresponding OpenGL (or Metal, if it's explicitly enabled) implementation part would be rolled back.

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

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

From avu at openjdk.java.net  Fri Mar 19 16:49:42 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 19 Mar 2021 16:49:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS
In-Reply-To: <KyIYKTNRgKBhP6VGRnmY3Jdpw8x2YGBzWe7uKgSisXE=.fd9aa403-c3cc-4a1c-8cad-3fb93bfdb85a@github.com>
References: <Zk5ZSOsPGxEkk5tzt2VcGkTfGsAVkNTWCuVSof5uvMs=.028ae9b7-fd8c-49da-a953-d4bbe7b9dffe@github.com>
 <h7KF3pw_yNMghXw5KjGgsJHgWCQFOj1cSiwdb-x-KQ8=.a378d29d-e4d9-4c2d-8eb8-e2ba0423298e@github.com>
 <RtpTWeSKgDVs0BKBbTrtGrWTzKLM2aW0_hUo0gni1-k=.952189ee-ffd6-4962-9541-d7c9888e9dbe@github.com>
 <9-0Gtuwqcg22dWmmXwr6eSOF_hSxEpA3J-F4Mc-rdYY=.12820f83-bf7e-453f-a262-da82c7001087@github.com>
 <auyqIoUUeLpZr-pRga_n1W2p9W95MFQnfot_0Vj6Wyk=.28acfb50-62af-4670-b3a0-f77b181d3371@github.com>
 <sAYyXJEYkIeDbaeZRXhitz86cWfwOh_s4DWg1xEtSzo=.8db7168b-b905-4de1-a28a-dea635e29930@github.com>
 <V_6L9ypRBgiVfbqDX6geP-_r4UD9RFBLFcof6hmL7sw=.47b979af-7b8b-421b-978a-198ae6d0e46e@github.com>
 <CTYqY1qg3m1Umd5uxTcTMSuMdVm9krDstxAxJ-dn3qs=.77819b22-00df-49f9-95fa-aa1f7e04e2eb@github.com>
 <KyIYKTNRgKBhP6VGRnmY3Jdpw8x2YGBzWe7uKgSisXE=.fd9aa403-c3cc-4a1c-8cad-3fb93bfdb85a@github.com>
Message-ID: <OAhTpgyzFyzTWBAxssurBGCnOS7_CLbEO9Mev5PJHgc=.c7fb76d0-16eb-4cfa-be9a-f578c8eb8b4e@github.com>

On Fri, 19 Mar 2021 13:54:34 GMT, Dmitry Batrak <dbatrak at openjdk.org> wrote:

>> You the current image from the MacEmoji test as a golden image for other formats/transforms/extraalpha/etc. For example, if DST type is changed then it is unlikely the shape of the emoji will be changed as well, or if it is too big/ too small.
>> 
>> BTW It will be good if the test will fail on the current metal implementation.
>
> Implementation for Metal pipeline has been added.
> 
> I've also updated the test case to check rendering into different types of images, including VolatileImage. The test will fail now, if corresponding OpenGL (or Metal, if it's explicitly enabled) implementation part would be rolled back.

Looks good!

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

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

From prr at openjdk.java.net  Fri Mar 19 18:15:39 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 19 Mar 2021 18:15:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8247370: Clean up unused printing code in
 awt_PrintJob.cpp
In-Reply-To: <mqjtHvDG1Sy0iWKqM6kKdaYlRJdx4TJB_eM9_IQ2lTo=.187ee3e4-ecce-4335-8848-c00b7b9d8ef4@github.com>
References: <91SED6lpn5sTusWtKDpsfECjI4PBPGAe3CdF9uYRsgk=.93533363-2e60-4172-8a41-f62c3df0ec83@github.com>
 <mqjtHvDG1Sy0iWKqM6kKdaYlRJdx4TJB_eM9_IQ2lTo=.187ee3e4-ecce-4335-8848-c00b7b9d8ef4@github.com>
Message-ID: <j9odmx5cvw7OXXwOApvwfeALXrU0SluB1_YOzvb3BJM=.0a632062-81f8-4771-95bc-eaf4dcd29995@github.com>

On Fri, 19 Mar 2021 04:45:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Maybe we should put noreg-cleanup in JBS.

done

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

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

From prr at openjdk.java.net  Fri Mar 19 18:15:40 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 19 Mar 2021 18:15:40 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8247370: Clean up unused printing code
 in awt_PrintJob.cpp
In-Reply-To: <91SED6lpn5sTusWtKDpsfECjI4PBPGAe3CdF9uYRsgk=.93533363-2e60-4172-8a41-f62c3df0ec83@github.com>
References: <91SED6lpn5sTusWtKDpsfECjI4PBPGAe3CdF9uYRsgk=.93533363-2e60-4172-8a41-f62c3df0ec83@github.com>
Message-ID: <7er2qh_ZyHJBUwbWKCuY2ndtj3lXQ2Q9uhByM34YAB8=.3b2f8903-ce28-4bb1-9edf-e00ebef99bef@github.com>

On Thu, 18 Mar 2021 22:59:57 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes a long time un-used code path.

This pull request has now been integrated.

Changeset: d41f7512
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d41f7512
Stats:     29 lines in 1 file changed: 0 ins; 19 del; 10 mod

8247370: Clean up unused printing code in awt_PrintJob.cpp

Reviewed-by: serb, psadhukhan

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

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

From aivanov at openjdk.java.net  Fri Mar 19 20:40:53 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 19 Mar 2021 20:40:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263894: Convert defaultPrinter and printers
 fields to local variables
Message-ID: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>

`PrintServiceLookupProvider` has `defaultPrinter` and `printers` fields but they are used only in `getDefaultPrintService()` and `refreshServices()` correspondingly. Thus these two fields can be converted to local variables in the corresponding methods.

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

Commit messages:
 - 8263894: Convert defaultPrinter and printers fields to local variables

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

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

From aivanov at openjdk.java.net  Fri Mar 19 20:42:46 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 19 Mar 2021 20:42:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263893: getPrinterNames() leaks nameArray if
 Java String allocation fails
Message-ID: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>

If `JNU_NewStringPlatform` fails to allocate new Java String object for printer name, `std::bad_alloc` is thrown. The handler for the exception does not release the local reference to the `nameArray`, thus it will be leaked.

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

Commit messages:
 - 8263893: getPrinterNames() leaks nameArray if Java String allocation fails

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

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

From prr at openjdk.java.net  Fri Mar 19 21:02:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 19 Mar 2021 21:02:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263893: getPrinterNames() leaks
 nameArray if Java String allocation fails
In-Reply-To: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
References: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
Message-ID: <ZAsPzJTXcTn0nybDpsjsaS5fvLk-oWM7jJq9GjY8SbQ=.d910e3fd-3e38-4e2b-9986-ae6524472f81@github.com>

On Fri, 19 Mar 2021 20:36:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If `JNU_NewStringPlatform` fails to allocate new Java String object for printer name, `std::bad_alloc` is thrown. The handler for the exception does not release the local reference to the `nameArray`, thus it will be leaked.

This is fine but there's not really a leak since when the caller returns to Java localrefs are released anyway.

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

Marked as reviewed by prr (Reviewer).

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

From prr at openjdk.java.net  Fri Mar 19 21:08:39 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 19 Mar 2021 21:08:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263894: Convert defaultPrinter and
 printers fields to local variables
In-Reply-To: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
References: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
Message-ID: <n0x3U5KzTd7YNvQcwRo0Q-ozd3HcMWxA69dX9_jKXSU=.692d1a5d-f35c-45e7-a13b-3f8d616077e4@github.com>

On Fri, 19 Mar 2021 20:35:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> `PrintServiceLookupProvider` has `defaultPrinter` and `printers` fields but they are used only in `getDefaultPrintService()` and `refreshServices()` correspondingly. Thus these two fields can be converted to local variables in the corresponding methods.

Why did you delete the comments ?

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

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

From aivanov at openjdk.java.net  Fri Mar 19 21:28:54 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 19 Mar 2021 21:28:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263894: Convert defaultPrinter and
 printers fields to local variables [v2]
In-Reply-To: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
References: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
Message-ID: <Lxnu_1y2n4X-AfV2yebuVLcp1uJZ0u26m_41EGeoUzA=.e6181055-420c-4764-9bf3-5211806e0d47@github.com>

> `PrintServiceLookupProvider` has `defaultPrinter` and `printers` fields but they are used only in `getDefaultPrintService()` and `refreshServices()` correspondingly. Thus these two fields can be converted to local variables in the corresponding methods.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Bring back the comment for printServices

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3095/files
  - new: https://git.openjdk.java.net/jdk/pull/3095/files/cfe460c2..2b98fec2

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

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

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

From aivanov at openjdk.java.net  Fri Mar 19 21:28:54 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 19 Mar 2021 21:28:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263894: Convert defaultPrinter and
 printers fields to local variables [v2]
In-Reply-To: <n0x3U5KzTd7YNvQcwRo0Q-ozd3HcMWxA69dX9_jKXSU=.692d1a5d-f35c-45e7-a13b-3f8d616077e4@github.com>
References: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
 <n0x3U5KzTd7YNvQcwRo0Q-ozd3HcMWxA69dX9_jKXSU=.692d1a5d-f35c-45e7-a13b-3f8d616077e4@github.com>
Message-ID: <xu2XWDf5p8A2gycrU9LVJW8gXuxb2ml-dtSNZdYFWfc=.c493cd2b-4602-462d-9422-6568bbfe22f5@github.com>

On Fri, 19 Mar 2021 21:05:57 GMT, Phil Race <prr at openjdk.org> wrote:

> Why did you delete the comments ?

The comments highlighted the difference between what is stored in `printers` and in `printServices`: _excludes_ vs. _includes_ the default printer. However, according to the code, `printers` _included_ the default printer too.

Now there's only `printServices` which contains all print services. I decided the comment didn't have much value now. Yet, upon thinking about it, the comment for `printServices` still provides additional insight: the array also contains the `defaultPrintService`.

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

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

From prr at openjdk.java.net  Fri Mar 19 21:51:42 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 19 Mar 2021 21:51:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263894: Convert defaultPrinter and
 printers fields to local variables [v2]
In-Reply-To: <Lxnu_1y2n4X-AfV2yebuVLcp1uJZ0u26m_41EGeoUzA=.e6181055-420c-4764-9bf3-5211806e0d47@github.com>
References: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
 <Lxnu_1y2n4X-AfV2yebuVLcp1uJZ0u26m_41EGeoUzA=.e6181055-420c-4764-9bf3-5211806e0d47@github.com>
Message-ID: <wqGC-oTgZA4ppw2-RV4F3Unhk_wXYDBb6jqcmqfJdEE=.7d804bc2-92bd-4821-9570-020ee3cc4776@github.com>

On Fri, 19 Mar 2021 21:28:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> `PrintServiceLookupProvider` has `defaultPrinter` and `printers` fields but they are used only in `getDefaultPrintService()` and `refreshServices()` correspondingly. Thus these two fields can be converted to local variables in the corresponding methods.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back the comment for printServices

Marked as reviewed by prr (Reviewer).

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

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

From azvegint at openjdk.java.net  Fri Mar 19 21:57:41 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 19 Mar 2021 21:57:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263894: Convert defaultPrinter and
 printers fields to local variables [v2]
In-Reply-To: <Lxnu_1y2n4X-AfV2yebuVLcp1uJZ0u26m_41EGeoUzA=.e6181055-420c-4764-9bf3-5211806e0d47@github.com>
References: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
 <Lxnu_1y2n4X-AfV2yebuVLcp1uJZ0u26m_41EGeoUzA=.e6181055-420c-4764-9bf3-5211806e0d47@github.com>
Message-ID: <ctWg-OVI4mv04ShO7GMjYE-d3bWgg8Lg_g_2Qdg8VNE=.a0f2541c-f257-4d52-9281-2b2add8d6040@github.com>

On Fri, 19 Mar 2021 21:28:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> `PrintServiceLookupProvider` has `defaultPrinter` and `printers` fields but they are used only in `getDefaultPrintService()` and `refreshServices()` correspondingly. Thus these two fields can be converted to local variables in the corresponding methods.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back the comment for printServices

Marked as reviewed by azvegint (Reviewer).

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

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

From azvegint at openjdk.java.net  Fri Mar 19 21:58:41 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 19 Mar 2021 21:58:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263893: getPrinterNames() leaks
 nameArray if Java String allocation fails
In-Reply-To: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
References: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
Message-ID: <2gV1q9oyFreMu5yNxu8c7tFbQl1CdEPP-acegpmxurc=.c55fe678-b594-4490-9f1f-3fa4d9451f5e@github.com>

On Fri, 19 Mar 2021 20:36:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If `JNU_NewStringPlatform` fails to allocate new Java String object for printer name, `std::bad_alloc` is thrown. The handler for the exception does not release the local reference to the `nameArray`, thus it will be leaked.

Marked as reviewed by azvegint (Reviewer).

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

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

From serb at openjdk.java.net  Fri Mar 19 22:34:39 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 19 Mar 2021 22:34:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263893: getPrinterNames() leaks
 nameArray if Java String allocation fails
In-Reply-To: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
References: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
Message-ID: <M7njJFT0qonzYIsr5lxXTeZvHeEAQj5F39qWk5lQPug=.dca4f7b3-466b-4af8-a0ad-0e45ab85be83@github.com>

On Fri, 19 Mar 2021 20:36:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If `JNU_NewStringPlatform` fails to allocate new Java String object for printer name, `std::bad_alloc` is thrown. The handler for the exception does not release the local reference to the `nameArray`, thus it will be leaked.

src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp line 178:

> 176:     } catch (std::bad_alloc&) {
> 177:         delete [] pPrinterEnum;
> 178:         if (nameArray != NULL) {

Not sure that we usually clean the local refs in the native JNI methods, that only required in the native loop which are never returned to the java(I have check that by the grep of env->NewObjectArray)

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sat Mar 20 07:48:39 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 20 Mar 2021 07:48:39 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263138: Initialization of
 sun.font.SunFontManager.platformFontMap is not thread safe
In-Reply-To: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
References: <VfbvqULL6u0Q08il6phHBn1i4klESxBdcwJfNnWDN2s=.5a4198b9-7e4c-4e42-b4cc-ecbdfe19ab53@github.com>
Message-ID: <ReG14G3Dge8CO2pvAHveKxusD1aND9Xl6hhvj8UXrcs=.20407d59-52c2-49e4-80c7-2d0cfe41d8a4@github.com>

On Sat, 27 Feb 2021 18:33:52 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe

This pull request has now been integrated.

Changeset: ab66d699
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab66d699
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8263138: Initialization of sun.font.SunFontManager.platformFontMap is not thread safe

Reviewed-by: aivanov, kizune, serb

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

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

From serb at openjdk.java.net  Sat Mar 20 07:50:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 20 Mar 2021 07:50:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263488: Verify CWarningWindow works with
 metal rendering pipeline
In-Reply-To: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
References: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
Message-ID: <QWL_1TnJh6ESsiVjAsPuKPUB_mKd3yqJXdpPmHQIpXk=.c768c811-2342-45e1-877a-1f468a8ae4d8@github.com>

On Fri, 19 Mar 2021 10:17:57 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : 
> CWarningWindow creates a MTLLayer with null peer.
> In MTLLayer.replaceSurfaceData() method, insets should be set only if peer is not null.
> 
> Fix : 
> Added the required null check.

Marked as reviewed by serb (Reviewer).

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

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

From pbansal at openjdk.java.net  Sat Mar 20 10:55:39 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 20 Mar 2021 10:55:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263488: Verify CWarningWindow works with
 metal rendering pipeline
In-Reply-To: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
References: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
Message-ID: <wnRQ_H5rZA9SeVitmrqsEieRMXKo0llZKVC2twarL2k=.6d4cc604-0cf6-4683-947d-72a33c19ba5a@github.com>

On Fri, 19 Mar 2021 10:17:57 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : 
> CWarningWindow creates a MTLLayer with null peer.
> In MTLLayer.replaceSurfaceData() method, insets should be set only if peer is not null.
> 
> Fix : 
> Added the required null check.

Marked as reviewed by pbansal (Reviewer).

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

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

From avu at openjdk.java.net  Sat Mar 20 14:56:39 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Sat, 20 Mar 2021 14:56:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263488: Verify CWarningWindow works with
 metal rendering pipeline
In-Reply-To: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
References: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
Message-ID: <QN2fLbO7HLyWOVEZXHxMt7dvSjl3topVkv9VQcq9C78=.cd509e48-5523-47f7-94e8-6e48e890113d@github.com>

On Fri, 19 Mar 2021 10:17:57 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : 
> CWarningWindow creates a MTLLayer with null peer.
> In MTLLayer.replaceSurfaceData() method, insets should be set only if peer is not null.
> 
> Fix : 
> Added the required null check.

Marked as reviewed by avu (no project role).

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

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

From kizune at openjdk.java.net  Sat Mar 20 18:15:37 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 20 Mar 2021 18:15:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263893: getPrinterNames() leaks
 nameArray if Java String allocation fails
In-Reply-To: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
References: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
Message-ID: <Rx6K45p4z8pCpIQRPSqk5Dkmqhrx0tYhNK0fSTUNOPo=.de1f5c22-9b2a-4cc3-a59a-f02a55dd5a03@github.com>

On Fri, 19 Mar 2021 20:36:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If `JNU_NewStringPlatform` fails to allocate new Java String object for printer name, `std::bad_alloc` is thrown. The handler for the exception does not release the local reference to the `nameArray`, thus it will be leaked.

Marked as reviewed by kizune (Reviewer).

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

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

From kizune at openjdk.java.net  Sat Mar 20 18:16:41 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 20 Mar 2021 18:16:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263488: Verify CWarningWindow works with
 metal rendering pipeline
In-Reply-To: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
References: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
Message-ID: <yvmPFZCytOBAoNOru9chLbvSBgBDjF0HInODcztSzqU=.3ca03e20-6baa-45ec-990d-59fb92bd2b54@github.com>

On Fri, 19 Mar 2021 10:17:57 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : 
> CWarningWindow creates a MTLLayer with null peer.
> In MTLLayer.replaceSurfaceData() method, insets should be set only if peer is not null.
> 
> Fix : 
> Added the required null check.

Marked as reviewed by kizune (Reviewer).

Marked as reviewed by kizune (Reviewer).

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

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

From kizune at openjdk.java.net  Sat Mar 20 18:16:40 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 20 Mar 2021 18:16:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263894: Convert defaultPrinter and
 printers fields to local variables [v2]
In-Reply-To: <Lxnu_1y2n4X-AfV2yebuVLcp1uJZ0u26m_41EGeoUzA=.e6181055-420c-4764-9bf3-5211806e0d47@github.com>
References: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
 <Lxnu_1y2n4X-AfV2yebuVLcp1uJZ0u26m_41EGeoUzA=.e6181055-420c-4764-9bf3-5211806e0d47@github.com>
Message-ID: <e09RrFzECjcm9cXOFzbgx9DZzc3n7qDUeQF63GuW3N4=.a794f5d6-e088-49c9-a823-cac06fadfb35@github.com>

On Fri, 19 Mar 2021 21:28:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> `PrintServiceLookupProvider` has `defaultPrinter` and `printers` fields but they are used only in `getDefaultPrintService()` and `refreshServices()` correspondingly. Thus these two fields can be converted to local variables in the corresponding methods.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back the comment for printServices

Marked as reviewed by kizune (Reviewer).

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

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

From aghaisas at openjdk.java.net  Mon Mar 22 02:48:42 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 22 Mar 2021 02:48:42 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263488: Verify CWarningWindow works
 with metal rendering pipeline
In-Reply-To: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
References: <MWy2UHJ6wGynunaqHKtLTreNT5erGnm5tNHQDjs0cAg=.45170f23-2c8a-46c7-996a-4ded1d1ea394@github.com>
Message-ID: <rcXM-CrClMPuP0q_YPME-P8T_3FoSzIy3X8VStSNtT8=.f336dafc-9b64-49c7-806a-ce7a9fc93271@github.com>

On Fri, 19 Mar 2021 10:17:57 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> Root cause : 
> CWarningWindow creates a MTLLayer with null peer.
> In MTLLayer.replaceSurfaceData() method, insets should be set only if peer is not null.
> 
> Fix : 
> Added the required null check.

This pull request has now been integrated.

Changeset: 42104e55
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42104e55
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8263488: Verify CWarningWindow works with metal rendering pipeline

Reviewed-by: serb, pbansal, avu, kizune

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

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

From akozlov at openjdk.java.net  Mon Mar 22 12:50:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 22 Mar 2021 12:50:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:

 - Merge branch 'master' into jdk-macos
 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch
 - 8262903: [macos_aarch64] Thread::current() called on detached thread
 - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=28
  Stats: 2947 lines in 75 files changed: 2838 ins; 27 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From aivanov at openjdk.java.net  Mon Mar 22 15:58:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 22 Mar 2021 15:58:39 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263894: Convert defaultPrinter and
 printers fields to local variables
In-Reply-To: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
References: <4rlGExbaSVVhKUUJRt27cMchZPp_4DJYRBfqZwwm93M=.0a987230-d810-422e-b400-48d20e8bf39a@github.com>
Message-ID: <ilx2i1H_BuftPhHvCmT9IML2CVeK2ubtr1Uay03aU0o=.56c9f075-9572-4039-9edc-2772b8408612@github.com>

On Fri, 19 Mar 2021 20:35:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> `PrintServiceLookupProvider` has `defaultPrinter` and `printers` fields but they are used only in `getDefaultPrintService()` and `refreshServices()` correspondingly. Thus these two fields can be converted to local variables in the corresponding methods.

This pull request has now been integrated.

Changeset: 840ab7bf
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/840ab7bf
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8263894: Convert defaultPrinter and printers fields to local variables

Reviewed-by: prr, azvegint, kizune

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

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

From shade at openjdk.java.net  Mon Mar 22 16:01:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 22 Mar 2021 16:01:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263981: java.awt.image.ComponentSampleModel
 equals/hashcode use numBands twice
Message-ID: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>

SonarCloud reports the problem in ComponentSampleModel.equals:
  Correct one of the identical sub-expressions on both sides of operator "&&"

...near "this.numBands == that.numBands". It is checked twice. hashCode also processes it twice.

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

Commit messages:
 - Update copyright line
 - JDK-8263981: java.awt.image.ComponentSampleModel equals/hashcode use numBands twice

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

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

From serb at openjdk.java.net  Mon Mar 22 17:46:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 22 Mar 2021 17:46:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263981:
 java.awt.image.ComponentSampleModel equals/hashcode use numBands twice
In-Reply-To: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
References: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
Message-ID: <4Bi_Pk9Wlm_Qv5vPRITz_9OKGbUijJrKwfMSElj3OJQ=.bbabb34a-79b4-4bb1-8a25-aa76d984ca39@github.com>

On Mon, 22 Mar 2021 15:55:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports the problem in ComponentSampleModel.equals:
>   Correct one of the identical sub-expressions on both sides of operator "&&"
> 
> ...near "this.numBands == that.numBands". It is checked twice. hashCode also processes it twice.

Marked as reviewed by serb (Reviewer).

src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 1228:

> 1226:         }
> 1227:         hash ^= numBands;
> 1228:         hash <<= 8;

Since this mistake was done in two places I think this is a typo here and not an intentional thing.

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

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

From shade at openjdk.java.net  Mon Mar 22 17:51:46 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 22 Mar 2021 17:51:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263981:
 java.awt.image.ComponentSampleModel equals/hashcode use numBands twice
In-Reply-To: <4Bi_Pk9Wlm_Qv5vPRITz_9OKGbUijJrKwfMSElj3OJQ=.bbabb34a-79b4-4bb1-8a25-aa76d984ca39@github.com>
References: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
 <4Bi_Pk9Wlm_Qv5vPRITz_9OKGbUijJrKwfMSElj3OJQ=.bbabb34a-79b4-4bb1-8a25-aa76d984ca39@github.com>
Message-ID: <zx4DFJ1PK4J9r_PotVHx1PH2D5IxnJQDBDrku8hCCTk=.61ec609e-3cf9-47f8-b0eb-4a1b2082a055@github.com>

On Mon, 22 Mar 2021 17:44:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> SonarCloud reports the problem in ComponentSampleModel.equals:
>>   Correct one of the identical sub-expressions on both sides of operator "&&"
>> 
>> ...near "this.numBands == that.numBands". It is checked twice. hashCode also processes it twice.
>
> src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 1228:
> 
>> 1226:         }
>> 1227:         hash ^= numBands;
>> 1228:         hash <<= 8;
> 
> Since this mistake was done in two places I think this is a typo here and not an intentional thing.

I am a bit confused by this comment :) I suspect that `equals` got duplicated `numBands` first, and then whoever did the `hashcode` just hashed the same fields in the same order, duplicating it again.

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

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

From serb at openjdk.java.net  Mon Mar 22 18:04:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 22 Mar 2021 18:04:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263981:
 java.awt.image.ComponentSampleModel equals/hashcode use numBands twice
In-Reply-To: <zx4DFJ1PK4J9r_PotVHx1PH2D5IxnJQDBDrku8hCCTk=.61ec609e-3cf9-47f8-b0eb-4a1b2082a055@github.com>
References: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
 <4Bi_Pk9Wlm_Qv5vPRITz_9OKGbUijJrKwfMSElj3OJQ=.bbabb34a-79b4-4bb1-8a25-aa76d984ca39@github.com>
 <zx4DFJ1PK4J9r_PotVHx1PH2D5IxnJQDBDrku8hCCTk=.61ec609e-3cf9-47f8-b0eb-4a1b2082a055@github.com>
Message-ID: <QlNpbKQD-SDOOSLzWOYb6LI7pgwqXc6gErJ4amxPUCA=.bb79b312-94b9-4bf2-b42f-27702a612a31@github.com>

On Mon, 22 Mar 2021 17:48:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 1228:
>> 
>>> 1226:         }
>>> 1227:         hash ^= numBands;
>>> 1228:         hash <<= 8;
>> 
>> Since this mistake was done in two places I think this is a typo here and not an intentional thing.
>
> I am a bit confused by this comment :) I suspect that `equals` got duplicated `numBands` first, and then whoever did the `hashcode` just hashed the same fields in the same order, duplicating it again.

I hope so, and not in the opposite order. I'll try to check the history f this file.

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

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

From azvegint at openjdk.java.net  Mon Mar 22 18:07:38 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 22 Mar 2021 18:07:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263981:
 java.awt.image.ComponentSampleModel equals/hashcode use numBands twice
In-Reply-To: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
References: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
Message-ID: <ePGJwIcoLuGhHnU4kElaIflVIUPiLdIflrtsWeQ6E2g=.214fd2c5-5a2f-43b4-8699-b907079865e1@github.com>

On Mon, 22 Mar 2021 15:55:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports the problem in ComponentSampleModel.equals:
>   Correct one of the identical sub-expressions on both sides of operator "&&"
> 
> ...near "this.numBands == that.numBands". It is checked twice. hashCode also processes it twice.

Marked as reviewed by azvegint (Reviewer).

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

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

From rajat.m.mahajan at oracle.com  Mon Mar 22 20:55:03 2021
From: rajat.m.mahajan at oracle.com (Rajat Mahajan)
Date: Mon, 22 Mar 2021 20:55:03 +0000
Subject: [OpenJDK 2D-Dev] Clarification regarding PageFormat and Paper
 getImageable* functions orientation consideration
Message-ID: <BN7PR10MB25649A0648DFBA86DD345E23C2659@BN7PR10MB2564.namprd10.prod.outlook.com>

Hi all,

Issue:

I am working on https://bugs.openjdk.java.net/browse/JDK-8203395  and this bug is about "PageFormat showing wrong printer margins in LANDSCAPE orientation" .

Application code it trying to print in Landscape and Portrait but both show same margins:

Margins default : 12,12,17,17
Margins OrientationRequested.LANDSCAPE : 12,12,17,17

The code of the application uses Paper object for getting margins :

PageFormat pf = printerJob.getPageFormat(aset);

       Paper paper = pf.getPaper();

       long paperTopMargin = Math.round(paper.getImageableY());
       long paperLeftMargin = Math.round(paper.getImageableX());
       long paperRightMargin = Math.round(paper.getWidth() - paper.getImageableWidth() - paperLeftMargin);
       long paperBottomMargin = Math.round(paper.getHeight() - paper.getImageableHeight() - paperTopMargin);

When I looked at the latest JDK code, PageFormat getImageable functions are taking into account Orientation and Paper getImageable functions are not , and hence we see the same output.

Using Page format object instead of Paper shows the correct output:

Margins default : 12,12,17,17
Margins OrientationRequested.LANDSCAPE : 17,17,12,12

Question:

My question is that should Paper getImageable* functions also need take into account orientation as per spec ?, or is the current behavior of them not considering orientation correct and why ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210322/adaa04a7/attachment.htm>

From philip.race at oracle.com  Mon Mar 22 21:54:46 2021
From: philip.race at oracle.com (Philip Race)
Date: Mon, 22 Mar 2021 14:54:46 -0700
Subject: [OpenJDK 2D-Dev] Clarification regarding PageFormat and Paper
 getImageable* functions orientation consideration
In-Reply-To: <BN7PR10MB25649A0648DFBA86DD345E23C2659@BN7PR10MB2564.namprd10.prod.outlook.com>
References: <BN7PR10MB25649A0648DFBA86DD345E23C2659@BN7PR10MB2564.namprd10.prod.outlook.com>
Message-ID: <b5450082-1716-7c19-6576-e73e218ff7bc@oracle.com>

There's no bug here from what I am being shown.

 >"PageFormat showing wrong printer margins in LANDSCAPE orientation? .

Really ? But I don't see anywhere the PageFormat is queried for this.
Instead the test case digs inside the PageFormat and retrieves the Paper 
and asks for *its* margins

I see a comment in the bug :
 > All getImageable methodes javadoc say "This method takes into account 
the orientation of the page" but It's not true before printing.

The methods that say that, are the ones on PageFormat, not the ones on 
Paper. So wrong.


-phil

On 3/22/21 1:55 PM, Rajat Mahajan wrote:
>
> Hi all,
>
> *_Issue:_*
>
> *__*
>
> I am working on https://bugs.openjdk.java.net/browse/JDK-8203395 
> <https://bugs.openjdk.java.net/browse/JDK-8203395> ?and this bug is 
> about *?PageFormat showing wrong printer margins in LANDSCAPE 
> orientation? .*
>
> **
>
> *Application code it trying to print in Landscape and Portrait but 
> both show same margins:*
>
> Margins default : 12,12,17,17
>
> Margins OrientationRequested.LANDSCAPE : 12,12,17,17
>
> **
>
> *The code of the application uses Paper object for getting margins :*
>
> PageFormat pf = printerJob.getPageFormat(aset);
>
> ???????Paper paper = pf.getPaper();
>
> ???????long paperTopMargin = Math.round(paper.getImageableY());
> ???????long paperLeftMargin = Math.round(paper.getImageableX());
> ???????long paperRightMargin = Math.round(paper.getWidth() - 
> paper.getImageableWidth() - paperLeftMargin);
> ???????long paperBottomMargin = Math.round(paper.getHeight() - 
> paper.getImageableHeight() - paperTopMargin);
>
> When I looked at the latest JDK code, PageFormat getImageable 
> functions are taking into account Orientation and Paper getImageable 
> functions are not , and hence we see the same output.
>
> Using Page format object instead of Paper shows the correct output:
>
> Margins default : 12,12,17,17
>
> Margins OrientationRequested.LANDSCAPE : 17,17,12,12
>
> *_Question:_*
>
> My question is that should Paper getImageable* functions also need 
> take into account orientation as per spec ?, or is the current 
> behavior of them not considering orientation correct and why ?
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210322/78ee1ff3/attachment-0001.htm>

From serb at openjdk.java.net  Tue Mar 23 05:00:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 23 Mar 2021 05:00:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264002: Delete outdated assumptions about
 ColorSpace initialization
Message-ID: <v3uK68MJ15HMf_ZboeK_zPi0t37eFbXArw2c45GWVLw=.39e835c5-7ed8-4777-bd92-b867acd6afb0@github.com>

Some codes have outdated assumptions about the initialization of ColorSpace class.
 - The ColorSpace.getInstance() will never throw an IllegalArgumentException for the builtin profiles
 - The ColorSpace.getInstance() will not trigger initialisation of the CMM classes

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

Commit messages:
 - Initial version

Changes: https://git.openjdk.java.net/jdk/pull/3140/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3140&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264002
  Stats: 168 lines in 6 files changed: 45 ins; 94 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3140.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3140/head:pull/3140

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

From serb at openjdk.java.net  Tue Mar 23 05:00:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 23 Mar 2021 05:00:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264002: Delete outdated assumptions
 about ColorSpace initialization
In-Reply-To: <v3uK68MJ15HMf_ZboeK_zPi0t37eFbXArw2c45GWVLw=.39e835c5-7ed8-4777-bd92-b867acd6afb0@github.com>
References: <v3uK68MJ15HMf_ZboeK_zPi0t37eFbXArw2c45GWVLw=.39e835c5-7ed8-4777-bd92-b867acd6afb0@github.com>
Message-ID: <zP3EHKVfyjg-DOpArYWtJm1Asvk0ogSXvT_48RdYLQA=.8b22804a-b1ae-4b93-b54d-27d958e205d4@github.com>

On Tue, 23 Mar 2021 00:14:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some codes have outdated assumptions about the initialization of ColorSpace class.
>  - The ColorSpace.getInstance() will never throw an IllegalArgumentException for the builtin profiles
>  - The ColorSpace.getInstance() will not trigger initialisation of the CMM classes

src/java.desktop/share/classes/com/sun/imageio/plugins/common/ImageUtil.java line 1175:

> 1173:                 && !cs.equals(ColorSpace.getInstance(ColorSpace.CS_CIEXYZ))
> 1174:                 && !cs.equals(ColorSpace.getInstance(ColorSpace.CS_PYCC));
> 1175:     }

The method above was added by the tiff implementation in jdk9 and it is mostly a copy of the older code in the jpeg plugin. I merged two methods and leave it here in the "common" code.

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java line 205:

> 203:      * of the CMM class until someone actually needs it.
> 204:      * (e.g. do not init CMM on the request for jpeg mime types)
> 205:      */

It is not necessary to delay the usage of ColorSpace, it itself defers the usage of cmm.

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

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

From shade at openjdk.java.net  Tue Mar 23 06:52:48 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 23 Mar 2021 06:52:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263981:
 java.awt.image.ComponentSampleModel equals/hashcode use numBands twice
In-Reply-To: <QlNpbKQD-SDOOSLzWOYb6LI7pgwqXc6gErJ4amxPUCA=.bb79b312-94b9-4bf2-b42f-27702a612a31@github.com>
References: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
 <4Bi_Pk9Wlm_Qv5vPRITz_9OKGbUijJrKwfMSElj3OJQ=.bbabb34a-79b4-4bb1-8a25-aa76d984ca39@github.com>
 <zx4DFJ1PK4J9r_PotVHx1PH2D5IxnJQDBDrku8hCCTk=.61ec609e-3cf9-47f8-b0eb-4a1b2082a055@github.com>
 <QlNpbKQD-SDOOSLzWOYb6LI7pgwqXc6gErJ4amxPUCA=.bb79b312-94b9-4bf2-b42f-27702a612a31@github.com>
Message-ID: <yoz7p-Ka2eaY5Tmp49t4n9eOa19HIrGto3cY75zCAeI=.525dc124-9d60-4bf4-ae1c-7ae65d226c5d@github.com>

On Mon, 22 Mar 2021 18:01:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I am a bit confused by this comment :) I suspect that `equals` got duplicated `numBands` first, and then whoever did the `hashcode` just hashed the same fields in the same order, duplicating it again.
>
> I hope so, and not in the opposite order. I'll try to check the history f this file.

Please do. I'll wait for a bit.

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

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

From aph at openjdk.java.net  Tue Mar 23 09:56:56 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 09:56:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v24]
In-Reply-To: <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
 <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
Message-ID: <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>

On Fri, 12 Mar 2021 16:32:10 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
>> 
>>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>>  - workaround JDK-8262895 by disabling subtest
>>  - Fix typo
>>  - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
>>  - JDK-8259937: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Fix after JDK-8259539, partially revert preconditions
>>  - JDK-8260471: bsd_aarch64 part
>>  - JDK-8259539: bsd_aarch64 part
>>  - JDK-8257828: bsd_aarch64 part
>>  - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834
>
>> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
> 
> I think that what you've got now is fine.

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
> 
> On 3/15/21 6:56 PM, Anton Kozlov wrote:
> 
> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley <aph at openjdk.org> wrote:
> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
> > > 
> > > 
> > > Robustness, clarity, maintainability, convention. Why not?
> > 
> > 
> > I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`).
> 
> No, no, no! I am not suggesting you change anything else, just that
> you do not define contentless macros. You might as well define it
> to be something, and true is a reasonable default, that's all. It's
> not terribly important, it's just good practice.

I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

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

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

From aph at openjdk.java.net  Tue Mar 23 09:56:57 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 09:56:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v24]
In-Reply-To: <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
 <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
 <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
Message-ID: <YVVYsQezst6QHcY0q_q-dmOYnzGiMdXaqabDahOmqO4=.1c0a67c6-1db1-4975-8c87-fb5308ac18dc@github.com>

On Tue, 23 Mar 2021 09:53:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
>> 
>> I think that what you've got now is fine.
>
>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
>> 
>> On 3/15/21 6:56 PM, Anton Kozlov wrote:
>> 
>> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley <aph at openjdk.org> wrote:
>> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
>> > > 
>> > > 
>> > > Robustness, clarity, maintainability, convention. Why not?
>> > 
>> > 
>> > I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`).
>> 
>> No, no, no! I am not suggesting you change anything else, just that
>> you do not define contentless macros. You might as well define it
>> to be something, and true is a reasonable default, that's all. It's
>> not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

So, where are we up to now? Are we done yet?

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

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

From vkempik at openjdk.java.net  Tue Mar 23 11:20:52 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 11:20:52 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v24]
In-Reply-To: <YVVYsQezst6QHcY0q_q-dmOYnzGiMdXaqabDahOmqO4=.1c0a67c6-1db1-4975-8c87-fb5308ac18dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
 <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
 <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
 <YVVYsQezst6QHcY0q_q-dmOYnzGiMdXaqabDahOmqO4=.1c0a67c6-1db1-4975-8c87-fb5308ac18dc@github.com>
Message-ID: <Rdc-1pvRQKF9q1HEI0zkO7Dgn5GAu1rgDZ_vH-5J5nM=.637e4903-b31d-4f06-8e98-473a057f13fc@github.com>

On Tue, 23 Mar 2021 09:54:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

> So, where are we up to now? Are we done yet?

Hello
we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17

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

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

From ihse at openjdk.java.net  Tue Mar 23 12:52:56 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 23 Mar 2021 12:52:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes still look good. Hope you can get this done now! :)

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

Marked as reviewed by ihse (Reviewer).

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

From erikj at openjdk.java.net  Tue Mar 23 12:52:55 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 23 Mar 2021 12:52:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <Xu_AFSUmt_tBHnpdHhAaUZOzuYq-L4_nGbwq_OMQk78=.8f69da0c-abd5-4688-855f-69cbbdc87770@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From akozlov at openjdk.java.net  Tue Mar 23 13:28:52 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 23 Mar 2021 13:28:52 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>
Message-ID: <VELjoQXnn9AqZJ5xS5fBeZITIpOuJ7_AyRr7Vxl5m0I=.8ec3a1cd-6af2-4bb7-9c43-2fa4a1474a24@github.com>

On Tue, 23 Mar 2021 12:49:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Build changes still look good. Hope you can get this done now! :)

> > No, no, no! I am not suggesting you change anything else, just that
> > you do not define contentless macros. You might as well define it
> > to be something, and true is a reasonable default, that's all. It's
> > not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

Sorry, I missed your reply.

R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change. 

The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
and https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137

But https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
and       
https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

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

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

From alexey.ivanov at oracle.com  Tue Mar 23 13:36:40 2021
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 23 Mar 2021 13:36:40 +0000
Subject: [OpenJDK 2D-Dev] Clarification regarding PageFormat and Paper
 getImageable* functions orientation consideration
In-Reply-To: <b5450082-1716-7c19-6576-e73e218ff7bc@oracle.com>
References: <BN7PR10MB25649A0648DFBA86DD345E23C2659@BN7PR10MB2564.namprd10.prod.outlook.com>
 <b5450082-1716-7c19-6576-e73e218ff7bc@oracle.com>
Message-ID: <63e42cfd-1783-efc3-543d-74db3f18fb30@oracle.com>

Hi Rajat,

I agree with Phil.

Both PageFormat [1] and Paper [2] have getImageable*() methods. The spec 
for each of these methods in PageFormat states, ?This method takes into 
account the orientation of the page.? The implementation confirms this 
statement.

Yet the spec for Paper does not have this statement.

The test case in JDK-8203395 [3] gets the margins from Paper object and 
it gets the same results, irrespective of the page orientation. This is 
*expected* because Paper does not take into account the orientation.

As you noticed, getting the margins from PageFormat object directly 
produces the expected result: the margins are different in portrait 
(default) and landscape orientation.

Thus both classes ? PageFormat and Paper ? behave exactly as specified.


As for the question:
> My question is that should Paper getImageable* functions also need 
> take into account orientation as per spec ?, or is the current 
> behavior of them not considering orientation correct and why ?
The Paper object doesn't have orientation. So I believe the current 
behaviour is correct.

-- 
Regards,
Alexey

[1] 
https://docs.oracle.com/javase/8/docs/api/java/awt/print/PageFormat.html#getImageableX--
https://docs.oracle.com/en/java/javase/16/docs/api/java.desktop/java/awt/print/PageFormat.html#getImageableX()
[2] 
https://docs.oracle.com/javase/8/docs/api/java/awt/print/Paper.html#getImageableX--
https://docs.oracle.com/en/java/javase/16/docs/api/java.desktop/java/awt/print/Paper.html#getImageableX()
[3]? https://bugs.openjdk.java.net/browse/JDK-8203395


On 22/03/2021 21:54, Philip Race wrote:
> There's no bug here from what I am being shown.
>
> >"PageFormat showing wrong printer margins in LANDSCAPE orientation? .
>
> Really ? But I don't see anywhere the PageFormat is queried for this.
> Instead the test case digs inside the PageFormat and retrieves the 
> Paper and asks for *its* margins
>
> I see a comment in the bug :
> > All getImageable methodes javadoc say "This method takes into 
> account the orientation of the page" but It's not true before printing.
>
> The methods that say that, are the ones on PageFormat, not the ones on 
> Paper. So wrong.
>
>
> -phil
>
> On 3/22/21 1:55 PM, Rajat Mahajan wrote:
>>
>> Hi all,
>>
>> *_Issue:_*
>>
>> *__*
>>
>> I am working on https://bugs.openjdk.java.net/browse/JDK-8203395 
>> <https://bugs.openjdk.java.net/browse/JDK-8203395> ?and this bug is 
>> about *?PageFormat showing wrong printer margins in LANDSCAPE 
>> orientation? .*
>>
>> **
>>
>> *Application code it trying to print in Landscape and Portrait but 
>> both show same margins:*
>>
>> Margins default : 12,12,17,17
>>
>> Margins OrientationRequested.LANDSCAPE : 12,12,17,17
>>
>> **
>>
>> *The code of the application uses Paper object for getting margins :*
>>
>> PageFormat pf = printerJob.getPageFormat(aset);
>>
>> ???????Paper paper = pf.getPaper();
>>
>> ???????long paperTopMargin = Math.round(paper.getImageableY());
>> ???????long paperLeftMargin = Math.round(paper.getImageableX());
>> ???????long paperRightMargin = Math.round(paper.getWidth() - 
>> paper.getImageableWidth() - paperLeftMargin);
>> ???????long paperBottomMargin = Math.round(paper.getHeight() - 
>> paper.getImageableHeight() - paperTopMargin);
>>
>> When I looked at the latest JDK code, PageFormat getImageable 
>> functions are taking into account Orientation and Paper getImageable 
>> functions are not , and hence we see the same output.
>>
>> Using Page format object instead of Paper shows the correct output:
>>
>> Margins default : 12,12,17,17
>>
>> Margins OrientationRequested.LANDSCAPE : 17,17,12,12
>>
>> *_Question:_*
>>
>> My question is that should Paper getImageable* functions also need 
>> take into account orientation as per spec ?, or is the current 
>> behavior of them not considering orientation correct and why ?
>>
>


From vkempik at openjdk.java.net  Tue Mar 23 13:47:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 13:47:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <VELjoQXnn9AqZJ5xS5fBeZITIpOuJ7_AyRr7Vxl5m0I=.8ec3a1cd-6af2-4bb7-9c43-2fa4a1474a24@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>
 <VELjoQXnn9AqZJ5xS5fBeZITIpOuJ7_AyRr7Vxl5m0I=.8ec3a1cd-6af2-4bb7-9c43-2fa4a1474a24@github.com>
Message-ID: <T87R9g8k9sUgph0vNreusY9OU1KJ438OoWvqz75qNfY=.05d35de2-8566-4f10-8780-86e79bbce005@github.com>

On Tue, 23 Mar 2021 13:26:19 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Build changes still look good. Hope you can get this done now! :)
>
>> > No, no, no! I am not suggesting you change anything else, just that
>> > you do not define contentless macros. You might as well define it
>> > to be something, and true is a reasonable default, that's all. It's
>> > not terribly important, it's just good practice.
>> 
>> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.
> 
> Sorry, I missed your reply.
> 
> R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change. 
> 
> The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
> and https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137
> 
> But https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
> and       
> https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

Hello
That depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

> 23 ????? 2021 ?., ? 16:39, drej1 ***@***.***> ???????(?):
> 
> 
> So, where are we up to now? Are we done yet?
> 
> Hello
> we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17
> 
> Hi there, will this be also supported backwards? To support java11 LTS version?
> 
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jdk/pull/2200#issuecomment-804910300>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQS2KRC6LT7BKA37RMS5I5DTFCKX7ANCNFSM4WO4SQXQ>.
>

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

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

From aivanov at openjdk.java.net  Tue Mar 23 13:51:52 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 23 Mar 2021 13:51:52 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there
 are no printers
Message-ID: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>

When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before.

The old print services should be invalidated.

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

Commit messages:
 - 8263984: Invalidate printServices when there are no printers

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

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

From aivanov at openjdk.java.net  Tue Mar 23 13:54:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 23 Mar 2021 13:54:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when
 there are no printers
In-Reply-To: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
References: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
Message-ID: <9tdpjbSGnLHFKCepG9in8FdsVRRnBs_eFw0jHiLaiqY=.39d27368-2b34-4ecc-bf89-f56090a38821@github.com>

On Tue, 23 Mar 2021 13:45:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before.
> 
> The old print services should be invalidated.

src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java line 116:

> 114:     private synchronized void refreshServices() {
> 115:         String[] printers = getAllPrinterNames();
> 116:         if (printers == null) {

`getAllPrinterNames` returns null when an error occurs or when there are no printers in the system.

Up for discussion:
If an error occurs, we may leave the old services without invalidating them. In this case, it is necessary to distinguish between the error and the lack of printers in the system. Does this make any sense?

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

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

From aph at openjdk.java.net  Tue Mar 23 13:56:59 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 13:56:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by aph (Reviewer).

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

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

From aph at openjdk.java.net  Tue Mar 23 14:00:58 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 14:00:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
Message-ID: <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>

On Tue, 23 Mar 2021 13:54:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by aph (Reviewer).

> [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

To the extent that 11u has fixed policies :)  we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

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

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

From aivanov at openjdk.java.net  Tue Mar 23 14:02:41 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 23 Mar 2021 14:02:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when
 there are no printers
In-Reply-To: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
References: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
Message-ID: <_tzSAlqGwvdnxNQOwbjyodFgbxJvkAlDMX9Mi3qOkrM=.b0fcf1b1-61b9-40b1-8e30-74edae00e9d4@github.com>

On Tue, 23 Mar 2021 13:45:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before.
> 
> The old print services should be invalidated.

src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java line 119:

> 117:             // In Windows it is safe to assume no default if printers == null so we
> 118:             // don't get the default.
> 119:             invalidateServices();

The default printer service, `defaultPrintService`, is usually in `printServices` array. It's possible that it's not in the array; in this case getDefaultPrintService() will reset it to `null` when accessed.

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

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

From vkempik at openjdk.java.net  Tue Mar 23 14:03:52 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 14:03:52 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
 <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>
Message-ID: <sEsT_ZQ0CBgs8Xc8h1NE32bgZ9SGwyIZ2o8Jl8Hx5cY=.3febcdec-8b29-457a-82fa-123c2a98c328@github.com>

On Tue, 23 Mar 2021 13:58:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> 
> To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

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

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

From mbeckwit at openjdk.java.net  Tue Mar 23 14:27:53 2021
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 23 Mar 2021 14:27:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <sEsT_ZQ0CBgs8Xc8h1NE32bgZ9SGwyIZ2o8Jl8Hx5cY=.3febcdec-8b29-457a-82fa-123c2a98c328@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
 <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>
 <sEsT_ZQ0CBgs8Xc8h1NE32bgZ9SGwyIZ2o8Jl8Hx5cY=.3febcdec-8b29-457a-82fa-123c2a98c328@github.com>
Message-ID: <yPvOw_97zvTpNmDvNRx0B8qqBIoqlnbJY5erdMrSTog=.0be084ee-92cd-4466-9120-9079aa5d9db3@github.com>

On Tue, 23 Mar 2021 14:01:12 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> > 
> > 
> > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
> 
> @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

Thanks, @theRealAph, and @VladimirKempik . We are on it!

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

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

From sgehwolf at openjdk.java.net  Tue Mar 23 15:23:53 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 23 Mar 2021 15:23:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm' in
 libjavajpeg and libawt
Message-ID: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>

The suggestion is to rename 'jvm' variable in `libjavajpeg` to `the_jvm` so this conflict no longer occurs when `libjavajpeg.a` and `libawt.a` are being linked into one native image.

Testing: test/jdk/javax/imageio jtreg tests. GHA pre-integration tests running too.

Thoughts?

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

Commit messages:
 - 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt

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

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

From mbeckwit at openjdk.java.net  Tue Mar 23 15:27:56 2021
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 23 Mar 2021 15:27:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <8y8WYVmVF_qrroxDo516Ucz1qWX5kMpPQHeqZgJNI2Q=.004fe86c-2b18-4a90-8499-1a34e64da3db@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by mbeckwit (Author).

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

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

From luhenry at openjdk.java.net  Tue Mar 23 16:23:54 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 23 Mar 2021 16:23:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by luhenry (Author).

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

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

From aph at openjdk.java.net  Tue Mar 23 16:36:55 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 16:36:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>
Message-ID: <HVuUWfsnr8fqATnVU2b4S7VdSOwuKg1xxEZW-islB2g=.56d118c4-745d-4371-91a9-3bb250c9b7a3@github.com>

On Tue, 23 Mar 2021 16:20:47 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by luhenry (Author).

> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> > > 
> > > 
> > > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
> > 
> > 
> > @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)
> 
> Thanks, @theRealAph, and @VladimirKempik . We are on it!

It's going to be tricky to do in a really clean way, given some of the weirdnesses of the ABI. However, I think there's probably a need for it

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

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

From serb at openjdk.java.net  Tue Mar 23 22:20:39 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 23 Mar 2021 22:20:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263981:
 java.awt.image.ComponentSampleModel equals/hashcode use numBands twice
In-Reply-To: <yoz7p-Ka2eaY5Tmp49t4n9eOa19HIrGto3cY75zCAeI=.525dc124-9d60-4bf4-ae1c-7ae65d226c5d@github.com>
References: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
 <4Bi_Pk9Wlm_Qv5vPRITz_9OKGbUijJrKwfMSElj3OJQ=.bbabb34a-79b4-4bb1-8a25-aa76d984ca39@github.com>
 <zx4DFJ1PK4J9r_PotVHx1PH2D5IxnJQDBDrku8hCCTk=.61ec609e-3cf9-47f8-b0eb-4a1b2082a055@github.com>
 <QlNpbKQD-SDOOSLzWOYb6LI7pgwqXc6gErJ4amxPUCA=.bb79b312-94b9-4bf2-b42f-27702a612a31@github.com>
 <yoz7p-Ka2eaY5Tmp49t4n9eOa19HIrGto3cY75zCAeI=.525dc124-9d60-4bf4-ae1c-7ae65d226c5d@github.com>
Message-ID: <hellrKZlwiuATY9FZOm5YhkKJNBxmfMYbTu1O5LaVDI=.060f6389-49bf-456b-a94b-d541390ec60f@github.com>

On Tue, 23 Mar 2021 06:50:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I hope so, and not in the opposite order. I'll try to check the history f this file.
>
> Please do. I'll wait for a bit.

I have found this bug, and the fix for it just implemented both methods at once, so this is a typo.
https://bugs.openjdk.java.net/browse/JDK-4430788

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

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

From psadhukhan at openjdk.java.net  Wed Mar 24 05:26:38 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 24 Mar 2021 05:26:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with
 low DPI has bad quality on Windows [v2]
In-Reply-To: <Pv-3othcHkeCmAzzT4N-Yo6PgpSZDvWKpTAv64eMrlg=.db259733-c420-4ff7-8a66-284ce87994c0@github.com>
References: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
 <Pv-3othcHkeCmAzzT4N-Yo6PgpSZDvWKpTAv64eMrlg=.db259733-c420-4ff7-8a66-284ce87994c0@github.com>
Message-ID: <qnYde8UqV3hHkKtU2bWobnzw0sJ0pFpEdO4GczXA9z0=.8ed2d966-f9a4-4f6d-ab08-18370baf06d2@github.com>

On Thu, 18 Mar 2021 12:29:01 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
>> The GDI system used for text printing on Windows accepts only integer path coordinates.
>> Rounding GlyphVector outline coordinates leads to distorted printed text.
>> 
>> The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page".
>> 
>> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
>> 
>> The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
>> 
>> I tried to put wPrinterJob.beginPath()/endPath()  methods around wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape.
>> 
>> The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method.
>> The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() .
>> 
>> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix.
>> 
>> There are two failed automated tests which fail without the fix as well:
>> java/awt/print/PrinterJob/GlyphPositions.java 
>> java/awt/print/PrinterJob/PSQuestionMark.java
>> 
>> The following manual tests have issues on my system:
>> - `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static"
>> 
>> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons.
>> 
>> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
>> 
>> 
>> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain  print/pass/fail buttons and it is not possible to close the window.
>> 
>> - The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message:
>> java/awt/print/Dialog/DialogOrient.java
>> java/awt/print/Dialog/DialogType.java
>> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
>> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
>> java/awt/print/PrinterJob/PageDialogTest.java
>> java/awt/print/PrinterJob/PageRanges.java
>> java/awt/print/PrinterJob/PageRangesDlgTest.java
>> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
>> java/awt/print/PrinterJob/PrintLatinCJKTest.java
>> java/awt/print/PrinterJob/PrintTextTest.java
>> java/awt/print/PrinterJob/SwingUIText.java
>> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
>> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
>> java/awt/PrintJob/SaveDialogTitleTest.java
>
> Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use DASSERT to check SetGraphicsMode and WorldTransform results
>  - Change setGraphicsMode() type to void

Marked as reviewed by psadhukhan (Reviewer).

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

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

From shade at openjdk.java.net  Wed Mar 24 07:04:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 24 Mar 2021 07:04:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263981:
 java.awt.image.ComponentSampleModel equals/hashcode use numBands twice
In-Reply-To: <hellrKZlwiuATY9FZOm5YhkKJNBxmfMYbTu1O5LaVDI=.060f6389-49bf-456b-a94b-d541390ec60f@github.com>
References: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
 <4Bi_Pk9Wlm_Qv5vPRITz_9OKGbUijJrKwfMSElj3OJQ=.bbabb34a-79b4-4bb1-8a25-aa76d984ca39@github.com>
 <zx4DFJ1PK4J9r_PotVHx1PH2D5IxnJQDBDrku8hCCTk=.61ec609e-3cf9-47f8-b0eb-4a1b2082a055@github.com>
 <QlNpbKQD-SDOOSLzWOYb6LI7pgwqXc6gErJ4amxPUCA=.bb79b312-94b9-4bf2-b42f-27702a612a31@github.com>
 <yoz7p-Ka2eaY5Tmp49t4n9eOa19HIrGto3cY75zCAeI=.525dc124-9d60-4bf4-ae1c-7ae65d226c5d@github.com>
 <hellrKZlwiuATY9FZOm5YhkKJNBxmfMYbTu1O5LaVDI=.060f6389-49bf-456b-a94b-d541390ec60f@github.com>
Message-ID: <_EoyPo3iaecEH-l31WooBWigx87smQ_yGwzLJJdn_VU=.70af01ff-23d9-4ae1-8489-fdd3b3eccc61@github.com>

On Tue, 23 Mar 2021 22:17:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please do. I'll wait for a bit.
>
> I have found this bug, and the fix for it just implemented both methods at once, so this is a typo.
> https://bugs.openjdk.java.net/browse/JDK-4430788

Brilliant, thanks. I'll integrate now.

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

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

From shade at openjdk.java.net  Wed Mar 24 07:04:42 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 24 Mar 2021 07:04:42 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263981:
 java.awt.image.ComponentSampleModel equals/hashcode use numBands twice
In-Reply-To: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
References: <KgQd8qy1Pq-htk2y-q_A2e8qL6YTvqPgPP0CNNBF22A=.59ec5afd-421e-40bb-9a9b-95760fa4f345@github.com>
Message-ID: <xOA_i1hgRMajqtjo9pgYQofmm1ZeJIrb1RrAt5gaNyw=.343d9045-af5a-4f78-b4f9-eeda44e56f1f@github.com>

On Mon, 22 Mar 2021 15:55:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports the problem in ComponentSampleModel.equals:
>   Correct one of the identical sub-expressions on both sides of operator "&&"
> 
> ...near "this.numBands == that.numBands". It is checked twice. hashCode also processes it twice.

This pull request has now been integrated.

Changeset: cb776edf
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cb776edf
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8263981: java.awt.image.ComponentSampleModel equals/hashcode use numBands twice

Reviewed-by: serb, azvegint

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

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

From psadhukhan at openjdk.java.net  Wed Mar 24 09:19:42 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 24 Mar 2021 09:19:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when
 there are no printers
In-Reply-To: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
References: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
Message-ID: <hTxuf8471JmYgr3cNoSOhCIF407tLWf_Tn7VQQSXEBo=.90155a68-1c89-45d7-94cf-b237dc3c1852@github.com>

On Tue, 23 Mar 2021 13:45:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before.
> 
> The old print services should be invalidated.

src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java line 120:

> 118:             // don't get the default.
> 119:             invalidateServices();
> 120:             printServices = new PrintService[0];

I am not sure this call to invalidateServices() is needed as we are creating a new `printServices` object of 0 length so making the old printServices invalid is redundant as it is same global variable.

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

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

From aivanov at openjdk.java.net  Wed Mar 24 09:28:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 24 Mar 2021 09:28:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when
 there are no printers
In-Reply-To: <hTxuf8471JmYgr3cNoSOhCIF407tLWf_Tn7VQQSXEBo=.90155a68-1c89-45d7-94cf-b237dc3c1852@github.com>
References: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
 <hTxuf8471JmYgr3cNoSOhCIF407tLWf_Tn7VQQSXEBo=.90155a68-1c89-45d7-94cf-b237dc3c1852@github.com>
Message-ID: <HI2_cYbT9fNOzIvu1Y6lDwjm0NZs68PnrQtrURDSWKY=.7bfb9ca0-1e4d-474c-b0c8-be5b00a6529c@github.com>

On Wed, 24 Mar 2021 09:16:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before.
>> 
>> The old print services should be invalidated.
>
> src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java line 120:
> 
>> 118:             // don't get the default.
>> 119:             invalidateServices();
>> 120:             printServices = new PrintService[0];
> 
> I am not sure this call to invalidateServices() is needed as we are creating a new `printServices` object of 0 length so making the old printServices invalid is redundant as it is same global variable.

That's exactly the problem I am addressing.

In the regular case, the existing services left in `printServices` are invalidated before `newServices` is assigned to it. Yet no existing services are invalidated if all the printers were removed from the system.

Why is it needed to invalidate deleted services if the list of printers is updated and if at least one printer is left in the system? Why is it not needed to invalidate deleted services if all the printers are removed from the system?

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

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

From psadhukhan at openjdk.java.net  Wed Mar 24 13:10:41 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 24 Mar 2021 13:10:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when
 there are no printers
In-Reply-To: <HI2_cYbT9fNOzIvu1Y6lDwjm0NZs68PnrQtrURDSWKY=.7bfb9ca0-1e4d-474c-b0c8-be5b00a6529c@github.com>
References: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
 <hTxuf8471JmYgr3cNoSOhCIF407tLWf_Tn7VQQSXEBo=.90155a68-1c89-45d7-94cf-b237dc3c1852@github.com>
 <HI2_cYbT9fNOzIvu1Y6lDwjm0NZs68PnrQtrURDSWKY=.7bfb9ca0-1e4d-474c-b0c8-be5b00a6529c@github.com>
Message-ID: <-nssXzOVh4I__oMQjsjYlvgqtQQKm78fr3Xcd_yT0eY=.2a5f9dcd-e2c1-448e-aa41-29f8700385c1@github.com>

On Wed, 24 Mar 2021 09:25:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java line 120:
>> 
>>> 118:             // don't get the default.
>>> 119:             invalidateServices();
>>> 120:             printServices = new PrintService[0];
>> 
>> I am not sure this call to invalidateServices() is needed as we are creating a new `printServices` object of 0 length so making the old printServices invalid is redundant as it is same global variable.
>
> That's exactly the problem I am addressing.
> 
> In the regular case, the existing services left in `printServices` are invalidated before `newServices` is assigned to it. Yet no existing services are invalidated if all the printers were removed from the system.
> 
> Why is it needed to invalidate deleted services if the list of printers is updated and if at least one printer is left in the system? Why is it not needed to invalidate deleted services if all the printers are removed from the system?

Since this is windows specific code, I am not sure if system will not have any printers. I guess by default, Microsoft XPS Document Writer, Microsoft Print-to-PDF, Fax are present in printers list. That is the reason we do not have getPrintService() return 0 printer although there may not be any real printer present in windows system...reason for some failure in jtreg test which caused us to use `@key printer `tag in those tests to make real printers are configured.

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

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

From azvegint at openjdk.java.net  Wed Mar 24 17:16:40 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 24 Mar 2021 17:16:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264002: Delete outdated assumptions
 about ColorSpace initialization
In-Reply-To: <v3uK68MJ15HMf_ZboeK_zPi0t37eFbXArw2c45GWVLw=.39e835c5-7ed8-4777-bd92-b867acd6afb0@github.com>
References: <v3uK68MJ15HMf_ZboeK_zPi0t37eFbXArw2c45GWVLw=.39e835c5-7ed8-4777-bd92-b867acd6afb0@github.com>
Message-ID: <Xag1IF3Bwk8W9McTf4LvBBSZkxsFU5QPP74tWD0C-Rg=.1c2a15e6-3b09-487f-a11e-6fade5b3e64f@github.com>

On Tue, 23 Mar 2021 00:14:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some codes have outdated assumptions about the initialization of ColorSpace class.
>  - The ColorSpace.getInstance() will never throw an IllegalArgumentException for the builtin profiles
>  - The ColorSpace.getInstance() will not trigger initialisation of the CMM classes

Looks good to me.

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

Marked as reviewed by azvegint (Reviewer).

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

From aivanov at openjdk.java.net  Wed Mar 24 20:16:41 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 24 Mar 2021 20:16:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263893: getPrinterNames() leaks
 nameArray if Java String allocation fails
In-Reply-To: <M7njJFT0qonzYIsr5lxXTeZvHeEAQj5F39qWk5lQPug=.dca4f7b3-466b-4af8-a0ad-0e45ab85be83@github.com>
References: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
 <M7njJFT0qonzYIsr5lxXTeZvHeEAQj5F39qWk5lQPug=.dca4f7b3-466b-4af8-a0ad-0e45ab85be83@github.com>
Message-ID: <I2Uq9ru0x5WAgpyoPqtFIuS18FPQGwfvzYZ_xuRsGak=.89df713c-94cd-48b6-96ca-fc54ef16f3c7@github.com>

On Fri, 19 Mar 2021 22:31:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> If `JNU_NewStringPlatform` fails to allocate new Java String object for printer name, `std::bad_alloc` is thrown. The handler for the exception does not release the local reference to the `nameArray`, thus it will be leaked.
>
> src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp line 178:
> 
>> 176:     } catch (std::bad_alloc&) {
>> 177:         delete [] pPrinterEnum;
>> 178:         if (nameArray != NULL) {
> 
> Not sure that we usually clean the local refs in the native JNI methods, that only required in the native loop which are never returned to the java(I have check that by the grep of env->NewObjectArray)

You're right. It's not required: all local refs are cleared when the JNI method exits.
My reasoning was that `env->DeleteLocalRef(utf_str)` is called in the loop. Strictly, it's not required either. Yet if there's a large number of elements in the array, it could cause a problem.

I'm going to withdraw the PR as the fix is not necessary.

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

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

From aivanov at openjdk.java.net  Wed Mar 24 20:47:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 24 Mar 2021 20:47:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when
 there are no printers
In-Reply-To: <-nssXzOVh4I__oMQjsjYlvgqtQQKm78fr3Xcd_yT0eY=.2a5f9dcd-e2c1-448e-aa41-29f8700385c1@github.com>
References: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
 <hTxuf8471JmYgr3cNoSOhCIF407tLWf_Tn7VQQSXEBo=.90155a68-1c89-45d7-94cf-b237dc3c1852@github.com>
 <HI2_cYbT9fNOzIvu1Y6lDwjm0NZs68PnrQtrURDSWKY=.7bfb9ca0-1e4d-474c-b0c8-be5b00a6529c@github.com>
 <-nssXzOVh4I__oMQjsjYlvgqtQQKm78fr3Xcd_yT0eY=.2a5f9dcd-e2c1-448e-aa41-29f8700385c1@github.com>
Message-ID: <HwPf_Y7E3Gy69n5gaHBVLY9y0jOUPCSYwWrazkxu1Ic=.7e57e311-90a2-41df-ad71-ce74abb2562c@github.com>

On Wed, 24 Mar 2021 13:07:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Since this is windows specific code, I am not sure if system will not have any printers. I guess by default, Microsoft XPS Document Writer, Microsoft Print-to-PDF, Fax are present in printers list.

Yes, that's correct. But you can remove them. You can also configure the image so that these are not installed by default.

> That is the reason we do not have getPrintService() return 0 printer although there may not be any real printer present in windows system...reason for some failure in jtreg test which caused us to use `@key printer `tag in those tests to make real printers are configured.

I agree that getting zero printers in Windows is unlikely. But it's still possible.

Consider the following scenario: Let's assume there are 10 printers in the system. The user removes 5 of them. In this case, `invalidateService()` is called on the instances of `Win32PrintService` which were removed from the system.

Then the user removes the remaining 5 printers. In this case, `invalidateService()` is not called at all. If an application has references to any of these instances, they will continue to appear operational. However, the flag `isInvalid` in `Win32PrintService` is used in two methods only: `getPrinterState` and `getPrinterStateReasons`.

This fix is minor, probably this situation never occurs in the real life.

The difference in handling the deleted services caught my attention. If everyone agrees it's not problem, I'll withdraw the PR and close the bug as _Not an Issue_.

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

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

From serb at openjdk.java.net  Wed Mar 24 21:36:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 24 Mar 2021 21:36:40 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8264002: Delete outdated assumptions
 about ColorSpace initialization
In-Reply-To: <v3uK68MJ15HMf_ZboeK_zPi0t37eFbXArw2c45GWVLw=.39e835c5-7ed8-4777-bd92-b867acd6afb0@github.com>
References: <v3uK68MJ15HMf_ZboeK_zPi0t37eFbXArw2c45GWVLw=.39e835c5-7ed8-4777-bd92-b867acd6afb0@github.com>
Message-ID: <m4LZaQQ_oOmvt7nmN2AEH0bjJ9LOkfJjoXb_8wdhzY0=.ff19c77f-4f72-41b7-ace3-026e6c48f018@github.com>

On Tue, 23 Mar 2021 00:14:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Some codes have outdated assumptions about the initialization of ColorSpace class.
>  - The ColorSpace.getInstance() will never throw an IllegalArgumentException for the builtin profiles
>  - The ColorSpace.getInstance() will not trigger initialisation of the CMM classes

This pull request has now been integrated.

Changeset: cfc9aa34
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cfc9aa34
Stats:     168 lines in 6 files changed: 45 ins; 94 del; 29 mod

8264002: Delete outdated assumptions about ColorSpace initialization

Reviewed-by: azvegint

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

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

From sgehwolf at openjdk.java.net  Thu Mar 25 17:57:26 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 25 Mar 2021 17:57:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm'
 in libjavajpeg and libawt
In-Reply-To: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
Message-ID: <uPx67oo0dIg0S1s6lvnhC0kqiurq3IwY-dqm1RZOH1Y=.24c67520-7a8f-4b90-a35e-ea3a33529a1c@github.com>

On Tue, 23 Mar 2021 15:18:13 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The suggestion is to rename 'jvm' variable in `libjavajpeg` to `the_jvm` so this conflict no longer occurs when `libjavajpeg.a` and `libawt.a` are being linked into one native image.
> 
> Testing: test/jdk/javax/imageio jtreg tests. GHA pre-integration tests running too.
> 
> Thoughts?

Anyone?

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

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

From akozlov at openjdk.java.net  Thu Mar 25 18:14:06 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:06 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <n4vzkDG9kXNf_qMitLPTjoo8F7Zxd2W6FwBS2P-v5WA=.d5639e5b-2912-4d6f-9b8a-1f1bf79669a7@github.com>

On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

This pull request has now been integrated.

Changeset: dbc9e4b5
Author:    Anton Kozlov <akozlov at openjdk.org>
Committer: Vladimir Kempik <vkempik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dbc9e4b5
Stats:     2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod

8253795: Implementation of JEP 391: macOS/AArch64 Port
8253816: Support macOS W^X
8253817: Support macOS Aarch64 ABI in Interpreter
8253818: Support macOS Aarch64 ABI for compiled wrappers
8253819: Implement os/cpu for macOS/AArch64
8253839: Update tests and JDK code for macOS/Aarch64
8254941: Implement Serviceability Agent for macOS/AArch64
8255776: Change build system for macOS/AArch64
8262903: [macos_aarch64] Thread::current() called on detached thread

Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry

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

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

From akozlov at openjdk.java.net  Thu Mar 25 18:14:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v30]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <Jrz4tirzLXG971FqxgjEXuaXq0W2bgIfFIdmHi7iTxE=.5f3847bc-e82d-49b7-829d-b160167e6ef2@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 117 commits:

 - JDK-8261397: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Merge branch 'master' into jdk-macos
 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - ... and 107 more: https://git.openjdk.java.net/jdk/compare/b006f22f...d3629967

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=29
  Stats: 2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

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

From akozlov at openjdk.java.net  Thu Mar 25 18:14:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v29]
In-Reply-To: <HVuUWfsnr8fqATnVU2b4S7VdSOwuKg1xxEZW-islB2g=.56d118c4-745d-4371-91a9-3bb250c9b7a3@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>
 <HVuUWfsnr8fqATnVU2b4S7VdSOwuKg1xxEZW-islB2g=.56d118c4-745d-4371-91a9-3bb250c9b7a3@github.com>
Message-ID: <AZT2E7ZueFv02oR3VekvtEzPUeXZ9gYvzBo-9ImCMqg=.4e988c58-da72-4824-b86e-10c6b035b17a@github.com>

On Tue, 23 Mar 2021 16:33:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Marked as reviewed by luhenry (Author).
>
>> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
>> > > 
>> > > 
>> > > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
>> > 
>> > 
>> > @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)
>> 
>> Thanks, @theRealAph, and @VladimirKempik . We are on it!
> 
> It's going to be tricky to do in a really clean way, given some of the weirdnesses of the ABI. However, I think there's probably a need for it

The JEP was targeted to JDK17. So I propose to integrate this. 

Thank you all for the reviews, suggestions, discussions, and support!

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

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

From prr at openjdk.java.net  Thu Mar 25 18:23:25 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 25 Mar 2021 18:23:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm'
 in libjavajpeg and libawt
In-Reply-To: <uPx67oo0dIg0S1s6lvnhC0kqiurq3IwY-dqm1RZOH1Y=.24c67520-7a8f-4b90-a35e-ea3a33529a1c@github.com>
References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
 <uPx67oo0dIg0S1s6lvnhC0kqiurq3IwY-dqm1RZOH1Y=.24c67520-7a8f-4b90-a35e-ea3a33529a1c@github.com>
Message-ID: <wsuaPhzRspqeSLSfs89I4p4adnApLVCwgn-gZGkAxmA=.b4e1f6ba-65a6-4e91-8769-06eeedc0b3ff@github.com>

On Thu, 25 Mar 2021 17:54:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Anyone?

I guess I don't understand why this is the right solution.
If the symbol -in both cases - is made internal won't that be better ? I can't think why it needs to be exported.
Is the AWT one being used by some other client library ? If so may be that other library needs its own.
And calling it "jvm" is common so are these the only two ?

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

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

From kcr at openjdk.java.net  Thu Mar 25 20:19:27 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 25 Mar 2021 20:19:27 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <8Vo0sYp5M4FNk6DKP2URAChl60rTHV-MpMsSUQi0-Nk=.c1f6ac22-cc67-4072-8d75-80032979db2f@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

src/java.desktop/share/classes/java/applet/package-info.java line 39:

> 37:  * applet development environment.
> 38:  * <p>
> 39:  * @deprecated.  This package has been deprecated and may be removed in

Package declarations cannot have `@deprecated` tags, so `make docs` fails with this change. Also, since there is a tag here, the previous `<p>` is now empty and causes a warning. Both problems will be fixed by removing the `@deprecated` tag, while leaving the added text.

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

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

From herrick at openjdk.java.net  Thu Mar 25 22:58:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 25 Mar 2021 22:58:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations [v2]
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Andy Herrick 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 301 additional commits since the last revision:

 - 8189198: Add "forRemoval = true" to Applet API deprecations
 - Merge branch 'master' into 8189198
 - 8260862: JFR: New configure command for the jfr tool
   
   Reviewed-by: mgronlun
 - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
   
   Reviewed-by: bpb
 - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
   
   Reviewed-by: cjplummer, lmesnik, sspitsyn
 - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
   
   Reviewed-by: jnimeh
 - 8253795: Implementation of JEP 391: macOS/AArch64 Port
   8253816: Support macOS W^X
   8253817: Support macOS Aarch64 ABI in Interpreter
   8253818: Support macOS Aarch64 ABI for compiled wrappers
   8253819: Implement os/cpu for macOS/AArch64
   8253839: Update tests and JDK code for macOS/Aarch64
   8254941: Implement Serviceability Agent for macOS/AArch64
   8255776: Change build system for macOS/AArch64
   8262903: [macos_aarch64] Thread::current() called on detached thread
   
   Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
   Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
   Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
   Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
   Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
 - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
   
   Reviewed-by: adinn
 - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
   
   Reviewed-by: herrick, dcubed
 - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
   
   Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
 - ... and 291 more: https://git.openjdk.java.net/jdk/compare/ddfe8ec5...026f09c8

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2920/files
  - new: https://git.openjdk.java.net/jdk/pull/2920/files/1148f208..026f09c8

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

  Stats: 64315 lines in 2948 files changed: 41333 ins; 13022 del; 9960 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2920/head:pull/2920

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

From herrick at openjdk.java.net  Thu Mar 25 22:58:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 25 Mar 2021 22:58:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations [v2]
In-Reply-To: <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
 <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
 <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>
Message-ID: <tArFXdLPW8vkB0tQ-hZLGWSCFii-IBVY2md9t8TNSD8=.fcac7aad-39cc-4449-a046-6140be9cfbde@github.com>

On Wed, 17 Mar 2021 20:33:09 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>>> I cannot find any instances where the scope can be narrowed
>> 
>> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?
>
>> 
>> 
>> > I cannot find any instances where the scope can be narrowed
>> 
>> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?
> 
> These have the code pattern such as: 
> } else if (c instanceof JApplet) {
> putting '@SuppressWarnings("removal")' before the declaration of 'c' does not help, because the code is not an assignment to 'c'

pushed minor change to src/java.desktop/share/classes/java/applet/package-info.java as well as merge with master.

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

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

From kcr at openjdk.java.net  Thu Mar 25 23:27:37 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 25 Mar 2021 23:27:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <LC2l3Zo5eUjQhM6QcVCXZJ7PFh4op_NJSj15xFWPblg=.c02e5303-8b79-4ad8-bc4c-eab62698228f@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick 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 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/e2285595...026f09c8

Looks good.

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

Marked as reviewed by kcr (Author).

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

From iris at openjdk.java.net  Thu Mar 25 23:38:33 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 25 Mar 2021 23:38:33 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <Ge5orwjsQQS4sJiLXFYz2nVh9v4HCBf1tz3WlVpSGlU=.f6a8deb3-c66a-4eea-b35e-76a82c2fbf73@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick 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 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/8fcfe0bd...026f09c8

Marked as reviewed by iris (Reviewer).

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

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

From prr at openjdk.java.net  Thu Mar 25 23:51:33 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 25 Mar 2021 23:51:33 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8189198: Add "forRemoval = true" to
 Applet API deprecations [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <rX_M7QysdLlKt6uprI4OE3kPj_x721_7gNHPw8Q52aQ=.952d1e25-d194-408d-a50d-b92cc8c5c7c4@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick 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 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/00b7b36f...026f09c8

Marked as reviewed by prr (Reviewer).

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

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

From sgehwolf at openjdk.java.net  Fri Mar 26 10:07:26 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 26 Mar 2021 10:07:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm'
 in libjavajpeg and libawt
In-Reply-To: <wsuaPhzRspqeSLSfs89I4p4adnApLVCwgn-gZGkAxmA=.b4e1f6ba-65a6-4e91-8769-06eeedc0b3ff@github.com>
References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
 <uPx67oo0dIg0S1s6lvnhC0kqiurq3IwY-dqm1RZOH1Y=.24c67520-7a8f-4b90-a35e-ea3a33529a1c@github.com>
 <wsuaPhzRspqeSLSfs89I4p4adnApLVCwgn-gZGkAxmA=.b4e1f6ba-65a6-4e91-8769-06eeedc0b3ff@github.com>
Message-ID: <63cmJkj__FGjLXAILexJtIJ5SjOsFbOX1AXMnvmng0g=.f1ee24f8-41cc-451a-ac62-1f18f752af1f@github.com>

On Thu, 25 Mar 2021 18:20:36 GMT, Phil Race <prr at openjdk.org> wrote:

> > Anyone?
> 
> I guess I don't understand why this is the right solution.

Thanks for the feedback. I'm open to other approaches. I'm by no means an expert in this area, so you probably know better what the best solution would be.

> If the symbol -in both cases - is made internal won't that be better ? I can't think why it needs to be exported.

I don't know if that'll help the static linking case, I'll give it a try.

> Is the AWT one being used by some other client library ? If so may be that other library needs its own.

I don't think it is. `libawt.so` and `libjavajpeg.so` have each their own. The problem starts when static libraries of them `libawt.a` and `libjavajpeg.a` get linked into one executable. Then we end up with a name clash on the `jvm` symbol. See the bug for some details.

> And calling it "jvm" is common so are these the only two ?

Apparently so. At least no other conflicts were noticed when the following client libraries are in the mix:

libjavajpeg.a
liblcms.a
libfontmanager.a
libawt_headless.a
libawt.a
libharfbuzz.a

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

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

From prr at openjdk.java.net  Fri Mar 26 14:51:26 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 26 Mar 2021 14:51:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm'
 in libjavajpeg and libawt
In-Reply-To: <63cmJkj__FGjLXAILexJtIJ5SjOsFbOX1AXMnvmng0g=.f1ee24f8-41cc-451a-ac62-1f18f752af1f@github.com>
References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
 <uPx67oo0dIg0S1s6lvnhC0kqiurq3IwY-dqm1RZOH1Y=.24c67520-7a8f-4b90-a35e-ea3a33529a1c@github.com>
 <wsuaPhzRspqeSLSfs89I4p4adnApLVCwgn-gZGkAxmA=.b4e1f6ba-65a6-4e91-8769-06eeedc0b3ff@github.com>
 <63cmJkj__FGjLXAILexJtIJ5SjOsFbOX1AXMnvmng0g=.f1ee24f8-41cc-451a-ac62-1f18f752af1f@github.com>
Message-ID: <PL0Ka7Ire48wn7gf7e_32Jw_s_KPfjzN9PlXsCNOhJI=.4aeaebec-82cf-403a-b105-5449b8e87f37@github.com>

On Fri, 26 Mar 2021 10:04:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> Anyone?
>> 
>> I guess I don't understand why this is the right solution.
>> If the symbol -in both cases - is made internal won't that be better ? I can't think why it needs to be exported.
>> Is the AWT one being used by some other client library ? If so may be that other library needs its own.
>> And calling it "jvm" is common so are these the only two ?
>
>> > Anyone?
>> 
>> I guess I don't understand why this is the right solution.
> 
> Thanks for the feedback. I'm open to other approaches. I'm by no means an expert in this area, so you probably know better what the best solution would be.
> 
>> If the symbol -in both cases - is made internal won't that be better ? I can't think why it needs to be exported.
> 
> I don't know if that'll help the static linking case, I'll give it a try.
> 
>> Is the AWT one being used by some other client library ? If so may be that other library needs its own.
> 
> I don't think it is. `libawt.so` and `libjavajpeg.so` have each their own. The problem starts when static libraries of them `libawt.a` and `libjavajpeg.a` get linked into one executable. Then we end up with a name clash on the `jvm` symbol. See the bug for some details.
> 
>> And calling it "jvm" is common so are these the only two ?
> 
> Apparently so. At least no other conflicts were noticed when the following client libraries are in the mix:
> 
> libjavajpeg.a
> liblcms.a
> libfontmanager.a
> libawt_headless.a
> libawt.a
> libharfbuzz.a

The list of libraries doesn't seem to include xawt. Although I'd be astonished if it defined one since it links with awt.
But it also suggests you are only looking at one platform and perhaps that is because the problem is very specific
to your toolchain ? Actually why are you seeing it now and it has not been a problem before ?

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

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

From herrick at openjdk.java.net  Fri Mar 26 14:51:28 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 26 Mar 2021 14:51:28 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8189198: Add "forRemoval = true" to
 Applet API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <4WWT8Ziy2C8n3V8-SQqJ_SNHpYlyB1uO26I-Szzm29c=.d2041dca-362a-4285-a961-7f71635df559@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

This pull request has now been integrated.

Changeset: 57115fa2
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57115fa2
Stats:     73 lines in 22 files changed: 14 ins; 0 del; 59 mod

8189198: Add "forRemoval = true" to Applet API deprecations

Reviewed-by: iris, almatvee, kcr, prr

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

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

From sgehwolf at openjdk.java.net  Fri Mar 26 15:02:25 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 26 Mar 2021 15:02:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm'
 in libjavajpeg and libawt
In-Reply-To: <PL0Ka7Ire48wn7gf7e_32Jw_s_KPfjzN9PlXsCNOhJI=.4aeaebec-82cf-403a-b105-5449b8e87f37@github.com>
References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
 <uPx67oo0dIg0S1s6lvnhC0kqiurq3IwY-dqm1RZOH1Y=.24c67520-7a8f-4b90-a35e-ea3a33529a1c@github.com>
 <wsuaPhzRspqeSLSfs89I4p4adnApLVCwgn-gZGkAxmA=.b4e1f6ba-65a6-4e91-8769-06eeedc0b3ff@github.com>
 <63cmJkj__FGjLXAILexJtIJ5SjOsFbOX1AXMnvmng0g=.f1ee24f8-41cc-451a-ac62-1f18f752af1f@github.com>
 <PL0Ka7Ire48wn7gf7e_32Jw_s_KPfjzN9PlXsCNOhJI=.4aeaebec-82cf-403a-b105-5449b8e87f37@github.com>
Message-ID: <75CbTnQk86-Fp0xcJ86QSa7l6eQCjMXBA_e8oxmLn78=.19a8dff9-f2a5-4933-a116-cc13b7a9b9b0@github.com>

On Fri, 26 Mar 2021 14:49:02 GMT, Phil Race <prr at openjdk.org> wrote:

> The list of libraries doesn't seem to include xawt.

Yes. This is in context of Graal VM's native images. AFAIK there is no full xawt support yet. This is about the conflict of libawt and libjavajpeg. There are probably more.

> But it also suggests you are only looking at one platform and perhaps that is because the problem is very specific
> to your toolchain ? Actually why are you seeing it now and it has not been a problem before ?

Yes. This is on Linux x86_64 and with an OpenJDK built with GCC 10+. With gcc 10+ `-fno-common` is default:
https://gcc.gnu.org/gcc-10/porting_to.html

So the `libjavajpeg.a`, and `libawt.a` got compiled with `-fno-common`. Then when being linked into an executable together, the linker screams with this:


collect2: error: ld returned 1 exit status

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

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

From prr at openjdk.java.net  Fri Mar 26 19:58:34 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 26 Mar 2021 19:58:34 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some
 specification clean up
Message-ID: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>

https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but
it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation.
I've spent a lot of time on what is just small number of factory methods in Raster because there are so
many possible exceptions and in some cases they rely on other API they call to generate exceptions and
these may have not been documented or documented acc. to some long lost behavior.
I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that
ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about
always has to be an internal bug !

The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of
cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17
So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException
to IllegalArgumentException.
JCK conformance tests still pass so they must not test those conditions.

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

Commit messages:
 - 8255800: Raster creation methods need some specification clean up

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

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

From prr at openjdk.java.net  Fri Mar 26 20:18:25 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 26 Mar 2021 20:18:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need
 some specification clean up
In-Reply-To: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
References: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
Message-ID: <ZFgNZwQPQiOLAkdvy_BjccjxiwbjE11D3bHWWTMzv9k=.ef37f4e1-6118-4ac9-80b8-b02eeeb290e0@github.com>

On Fri, 26 Mar 2021 19:53:44 GMT, Phil Race <prr at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but
> it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation.
> I've spent a lot of time on what is just small number of factory methods in Raster because there are so
> many possible exceptions and in some cases they rely on other API they call to generate exceptions and
> these may have not been documented or documented acc. to some long lost behavior.
> I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that
> ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about
> always has to be an internal bug !
> 
> The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of
> cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17
> So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException
> to IllegalArgumentException.
> JCK conformance tests still pass so they must not test those conditions.

oh and yes I know this requires a CSR ! But I want to do the code review first and then submit a CSR based on the approved version.

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

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

From serb at openjdk.java.net  Fri Mar 26 20:51:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 26 Mar 2021 20:51:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need
 some specification clean up
In-Reply-To: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
References: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
Message-ID: <-0wFDhzgacQic6ii8fKr9N3HLDcQi5AjF-sNNznUGxg=.dabe42bd-2f95-4f12-be90-2a4a35be3234@github.com>

On Fri, 26 Mar 2021 19:53:44 GMT, Phil Race <prr at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but
> it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation.
> I've spent a lot of time on what is just small number of factory methods in Raster because there are so
> many possible exceptions and in some cases they rely on other API they call to generate exceptions and
> these may have not been documented or documented acc. to some long lost behavior.
> I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that
> ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about
> always has to be an internal bug !
> 
> The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of
> cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17
> So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException
> to IllegalArgumentException.
> JCK conformance tests still pass so they must not test those conditions.

src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 127:

> 125:      * @throws IllegalArgumentException if {@code pixelStride} is less than 0
> 126:      * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
> 127:      * @throws NullPointerException if {@code bandOffsets} is {@code null}

I like the NPE here, but probably it makes sense to use the same exception for all errors? "IllegalArgumentException "

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

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

From serb at openjdk.java.net  Fri Mar 26 20:53:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 26 Mar 2021 20:53:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when
 there are no printers
In-Reply-To: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
References: <WxjwW2Fxcatg8Bg41IHmfAdR6eaxciR5YmnQqxSv8ic=.03bf55e2-0916-4dab-bbb0-6a5e6e4b5958@github.com>
Message-ID: <TFDW1J-JK7VJ2TmRp474JaO4UpxSJHiBY5aOuyQMs2Q=.404838a0-c966-4c20-8638-2ff2d4021442@github.com>

On Tue, 23 Mar 2021 13:45:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before.
> 
> The old print services should be invalidated.

Marked as reviewed by serb (Reviewer).

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

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

From prr at openjdk.java.net  Fri Mar 26 22:48:25 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 26 Mar 2021 22:48:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need
 some specification clean up
In-Reply-To: <-0wFDhzgacQic6ii8fKr9N3HLDcQi5AjF-sNNznUGxg=.dabe42bd-2f95-4f12-be90-2a4a35be3234@github.com>
References: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
 <-0wFDhzgacQic6ii8fKr9N3HLDcQi5AjF-sNNznUGxg=.dabe42bd-2f95-4f12-be90-2a4a35be3234@github.com>
Message-ID: <vh5oLb4ErHoJRLEgNBwqej0Gnqyq974K7ZWPib1Koq8=.62f4a56a-03e2-47c1-988e-2399afd8ceca@github.com>

On Fri, 26 Mar 2021 20:48:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but
>> it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation.
>> I've spent a lot of time on what is just small number of factory methods in Raster because there are so
>> many possible exceptions and in some cases they rely on other API they call to generate exceptions and
>> these may have not been documented or documented acc. to some long lost behavior.
>> I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that
>> ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about
>> always has to be an internal bug !
>> 
>> The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of
>> cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17
>> So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException
>> to IllegalArgumentException.
>> JCK conformance tests still pass so they must not test those conditions.
>
> src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 127:
> 
>> 125:      * @throws IllegalArgumentException if {@code pixelStride} is less than 0
>> 126:      * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
>> 127:      * @throws NullPointerException if {@code bandOffsets} is {@code null}
> 
> I like the NPE here, but probably it makes sense to use the same exception for all errors? "IllegalArgumentException "

Meaning even though you like the NPE you would change it to IAE like the rest ?

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

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

From serb at openjdk.java.net  Sat Mar 27 01:00:28 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 27 Mar 2021 01:00:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm'
 in libjavajpeg and libawt
In-Reply-To: <75CbTnQk86-Fp0xcJ86QSa7l6eQCjMXBA_e8oxmLn78=.19a8dff9-f2a5-4933-a116-cc13b7a9b9b0@github.com>
References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
 <uPx67oo0dIg0S1s6lvnhC0kqiurq3IwY-dqm1RZOH1Y=.24c67520-7a8f-4b90-a35e-ea3a33529a1c@github.com>
 <wsuaPhzRspqeSLSfs89I4p4adnApLVCwgn-gZGkAxmA=.b4e1f6ba-65a6-4e91-8769-06eeedc0b3ff@github.com>
 <63cmJkj__FGjLXAILexJtIJ5SjOsFbOX1AXMnvmng0g=.f1ee24f8-41cc-451a-ac62-1f18f752af1f@github.com>
 <PL0Ka7Ire48wn7gf7e_32Jw_s_KPfjzN9PlXsCNOhJI=.4aeaebec-82cf-403a-b105-5449b8e87f37@github.com>
 <75CbTnQk86-Fp0xcJ86QSa7l6eQCjMXBA_e8oxmLn78=.19a8dff9-f2a5-4933-a116-cc13b7a9b9b0@github.com>
Message-ID: <ouSjxM_btQISCEujniMBIIaJXBPLhq2fLToFv-OxWj4=.bbfd311e-0fe1-4641-8734-c5ca4e438418@github.com>

On Fri, 26 Mar 2021 14:59:14 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The list of libraries doesn't seem to include xawt. Although I'd be astonished if it defined one since it links with awt.
>> But it also suggests you are only looking at one platform and perhaps that is because the problem is very specific
>> to your toolchain ? Actually why are you seeing it now and it has not been a problem before ?
>
>> The list of libraries doesn't seem to include xawt.
> 
> Yes. This is in context of Graal VM's native images. AFAIK there is no full xawt support yet. This is about the conflict of libawt and libjavajpeg. There are probably more.
> 
>> But it also suggests you are only looking at one platform and perhaps that is because the problem is very specific
>> to your toolchain ? Actually why are you seeing it now and it has not been a problem before ?
> 
> Yes. This is on Linux x86_64 and with an OpenJDK built with GCC 10+. With gcc 10+ `-fno-common` is default:
> https://gcc.gnu.org/gcc-10/porting_to.html
> 
> So the `libjavajpeg.a`, and `libawt.a` got compiled with `-fno-common`. Then when being linked into an executable together, the linker screams with this:
> 
> 
> collect2: error: ld returned 1 exit status

Probably it will be easy to remove this "jvm" variable in the jpeg library? Looks like it is used to call JNU_GetEnv, but the JNIEnv could be accessed from the first parameter of the jni method.

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

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

From serb at openjdk.java.net  Sat Mar 27 01:12:26 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 27 Mar 2021 01:12:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm'
 in libjavajpeg and libawt
In-Reply-To: <ouSjxM_btQISCEujniMBIIaJXBPLhq2fLToFv-OxWj4=.bbfd311e-0fe1-4641-8734-c5ca4e438418@github.com>
References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
 <uPx67oo0dIg0S1s6lvnhC0kqiurq3IwY-dqm1RZOH1Y=.24c67520-7a8f-4b90-a35e-ea3a33529a1c@github.com>
 <wsuaPhzRspqeSLSfs89I4p4adnApLVCwgn-gZGkAxmA=.b4e1f6ba-65a6-4e91-8769-06eeedc0b3ff@github.com>
 <63cmJkj__FGjLXAILexJtIJ5SjOsFbOX1AXMnvmng0g=.f1ee24f8-41cc-451a-ac62-1f18f752af1f@github.com>
 <PL0Ka7Ire48wn7gf7e_32Jw_s_KPfjzN9PlXsCNOhJI=.4aeaebec-82cf-403a-b105-5449b8e87f37@github.com>
 <75CbTnQk86-Fp0xcJ86QSa7l6eQCjMXBA_e8oxmLn78=.19a8dff9-f2a5-4933-a116-cc13b7a9b9b0@github.com>
 <ouSjxM_btQISCEujniMBIIaJXBPLhq2fLToFv-OxWj4=.bbfd311e-0fe1-4641-8734-c5ca4e438418@github.com>
Message-ID: <u_p80-uNO17LCxpWltfpOSl3ysEejIhbdrBmxvrwqO4=.79c7c85a-5dc0-4709-bc45-c1200d7894af@github.com>

On Sat, 27 Mar 2021 00:57:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably it will be easy to remove this "jvm" variable in the jpeg library? Looks like it is used to call JNU_GetEnv, but the JNIEnv could be accessed from the first parameter of the jni method.

Seems these methods are used as callbacks...

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

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

From sgehwolf at openjdk.java.net  Mon Mar 29 13:53:25 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 29 Mar 2021 13:53:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm'
 in libjavajpeg and libawt
In-Reply-To: <u_p80-uNO17LCxpWltfpOSl3ysEejIhbdrBmxvrwqO4=.79c7c85a-5dc0-4709-bc45-c1200d7894af@github.com>
References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
 <uPx67oo0dIg0S1s6lvnhC0kqiurq3IwY-dqm1RZOH1Y=.24c67520-7a8f-4b90-a35e-ea3a33529a1c@github.com>
 <wsuaPhzRspqeSLSfs89I4p4adnApLVCwgn-gZGkAxmA=.b4e1f6ba-65a6-4e91-8769-06eeedc0b3ff@github.com>
 <63cmJkj__FGjLXAILexJtIJ5SjOsFbOX1AXMnvmng0g=.f1ee24f8-41cc-451a-ac62-1f18f752af1f@github.com>
 <PL0Ka7Ire48wn7gf7e_32Jw_s_KPfjzN9PlXsCNOhJI=.4aeaebec-82cf-403a-b105-5449b8e87f37@github.com>
 <75CbTnQk86-Fp0xcJ86QSa7l6eQCjMXBA_e8oxmLn78=.19a8dff9-f2a5-4933-a116-cc13b7a9b9b0@github.com>
 <ouSjxM_btQISCEujniMBIIaJXBPLhq2fLToFv-OxWj4=.bbfd311e-0fe1-4641-8734-c5ca4e438418@github.com>
 <u_p80-uNO17LCxpWltfpOSl3ysEejIhbdrBmxvrwqO4=.79c7c85a-5dc0-4709-bc45-c1200d7894af@github.com>
Message-ID: <XdM1ARDgIl3LA91mr4r7xL4q-xkUhxemhdA4zrv1QME=.49e8c425-dbab-43c1-96be-bbda9e2e9a3b@github.com>

On Sat, 27 Mar 2021 01:09:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Probably it will be easy to remove this "jvm" variable in the jpeg library? Looks like it is used to call JNU_GetEnv, but the JNIEnv could be accessed from the first parameter of the jni method.
>
>> Probably it will be easy to remove this "jvm" variable in the jpeg library? Looks like it is used to call JNU_GetEnv, but the JNIEnv could be accessed from the first parameter of the jni method.
> 
> Seems these methods are used as callbacks...

So what's the verdict with this one? OK to rename the variable or go a different route?

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

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

From philip.race at oracle.com  Mon Mar 29 16:41:51 2021
From: philip.race at oracle.com (Philip Race)
Date: Mon, 29 Mar 2021 09:41:51 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> libfontmanager.so: undefined symbol:
 hb_font_destroy in openjdk17~14
In-Reply-To: <AzYFXg.4TjS8FJQjjVL.IOrWRGrbuQBC6W2V2UQe@freemail.hu>
References: <AzYFXg.4TjS8FJQjjVL.IOrWRGrbuQBC6W2V2UQe@freemail.hu>
Message-ID: <2548be46-db99-8242-c04c-ac98a939a6f0@oracle.com>

Moving this to the right list.

There's lots of missing information in your email.

1) I don't know what a debian sid is. Internet suggests it is some 
upstream dev version
Is this reproducible on any shipping distro ?

2) Where exactly did you get the openjdk build 17 ? Was it from 
https://jdk.java.net/17/ or somewhere else ?
Please show the output of "java -version" to help confirm it.

3) What does? "ls -l lib/libfontmanager.so" show ?

4) What was the JDK version you had immediately before this and where 
did you get that ?

5) Does either JDK 11u or JDK15u work in this respect on that system ?

-phil

On 3/19/21 6:03 AM, mc36 wrote:
> hi,
> just upgraded from openjdk17~11 to openjdk17~14 
> (https://packages.debian.org/sid/main/openjdk-17-jdk) on my debian 
> sid. i quickly noticed that something is wrong so i ended up with the 
> below sample app.
> i'm not a big c coder so all i was able to do is that i got the 
> libharfbuzz sources 
> (https://packages.debian.org/unstable/libharfbuzz-dev) and checked 
> that i have that version and the function is there.
> i would appreciate some idea what else should i try?
> thanks,
> csaba
>
>
> mc36 at noti:~$ cat a.java
>
> import java.awt.Graphics2D;
> import java.awt.image.BufferedImage;
>
> public class a {
>
> ??? public static void main(String[] args) throws Exception {
> ??????? BufferedImage img = new BufferedImage(100, 100, 
> BufferedImage.TYPE_INT_RGB);
> ??????? Graphics2D g2d = img.createGraphics();
> ??? }
>
> }
>
>
> mc36 at noti:~$ javac a.java
> mc36 at noti:~$ java a
> Exception in thread "main" java.lang.UnsatisfiedLinkError: 
> /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: 
> /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: undefined 
> symbol: hb_font_destroy
> ??????? at java.base/jdk.internal.loader.NativeLibraries.load(Native 
> Method)
> ??????? at 
> java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:383)
> ??????? at 
> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:227)
> ??????? at 
> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:169)
> ??????? at 
> java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:310)
> ??????? at 
> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:280)
> ??????? at 
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2392)
> ??????? at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:808)
> ??????? at java.base/java.lang.System.loadLibrary(System.java:1893)
> ??????? at 
> java.desktop/sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:57)
> ??????? at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
> ??????? at 
> java.desktop/sun.font.FontManagerNativeLibrary.<clinit>(FontManagerNativeLibrary.java:32)
> ??????? at 
> java.desktop/sun.java2d.xr.XRSurfaceData.initXRSurfaceData(XRSurfaceData.java:104)
> ??????? at 
> java.desktop/sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:122)
> ??????? at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
> ??????? at 
> java.desktop/sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:59)
> ??????? at 
> java.desktop/sun.awt.PlatformGraphicsInfo.createGE(PlatformGraphicsInfo.java:36)
> ??????? at 
> java.desktop/java.awt.GraphicsEnvironment$LocalGE.createGE(GraphicsEnvironment.java:93)
> ??????? at 
> java.desktop/java.awt.GraphicsEnvironment$LocalGE.<clinit>(GraphicsEnvironment.java:84)
> ??????? at 
> java.desktop/java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:106)
> ??????? at 
> java.desktop/java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1181)
> ??????? at a.main(a.java:9)
> mc36 at noti:~$


From serb at openjdk.java.net  Mon Mar 29 23:02:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 29 Mar 2021 23:02:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8012229: [lcms] Improve performance of color
 conversion for images with alpha channel
Message-ID: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>

The lcms 2.8 version added support for the cmsFLAGS_COPY_ALPHA flag:
https://sourceforge.net/p/lcms/mailman/lcms-user/thread/001c01d1c0f3%2484a7cb30%248df76190%24%40ProDigitalSoftware.com/#msg35143398

which supports alpha channel transportation

For our usage, it means we can use TYPE_4BYTE_ABGR and TYPE_INT_ARGB directly as a source and destination.

Some numbers; converting new BufferedImage(3000, 3000, TYPE_INT_ARGB) from CS_sRGB to CS_CIEXYZ via op.filter(src, dst):
//before the fix
//Benchmark                  Mode  Cnt    Score    Error  Units
//ColorAlphaConv.testFilter  avgt    5  603,392 ? 12,932  ms/op

//after the fix
//Benchmark                  Mode  Cnt    Score   Error  Units
//ColorAlphaConv.testFilter  avgt    5  121,624 ? 0,906  ms/op

But still slower than kcms
//kcms jdk8u60
//Benchmark                  Mode  Cnt   Score   Error  Units
//ColorAlphaConv.testFilter  avgt    5  13,256 ? 0,169  ms/op

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

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/3239/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3239&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8012229
  Stats: 208 lines in 5 files changed: 195 ins; 2 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3239.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3239/head:pull/3239

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

From serb at openjdk.java.net  Mon Mar 29 23:02:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 29 Mar 2021 23:02:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8012229: [lcms] Improve performance of
 color conversion for images with alpha channel
In-Reply-To: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>
References: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>
Message-ID: <4XScAxbcJqyPi5VNPBWGGZD1a4APCqr623AEHzS8I6w=.88574969-840c-4c9d-80ce-1e0312807bc9@github.com>

On Mon, 29 Mar 2021 07:36:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The lcms 2.8 version added support for the cmsFLAGS_COPY_ALPHA flag:
> https://sourceforge.net/p/lcms/mailman/lcms-user/thread/001c01d1c0f3%2484a7cb30%248df76190%24%40ProDigitalSoftware.com/#msg35143398
> 
> which supports alpha channel transportation
> 
> For our usage, it means we can use TYPE_4BYTE_ABGR and TYPE_INT_ARGB directly as a source and destination.
> 
> Some numbers; converting new BufferedImage(3000, 3000, TYPE_INT_ARGB) from CS_sRGB to CS_CIEXYZ via op.filter(src, dst):
> //before the fix
> //Benchmark                  Mode  Cnt    Score    Error  Units
> //ColorAlphaConv.testFilter  avgt    5  603,392 ? 12,932  ms/op
> 
> //after the fix
> //Benchmark                  Mode  Cnt    Score   Error  Units
> //ColorAlphaConv.testFilter  avgt    5  121,624 ? 0,906  ms/op
> 
> But still slower than kcms
> //kcms jdk8u60
> //Benchmark                  Mode  Cnt   Score   Error  Units
> //ColorAlphaConv.testFilter  avgt    5  13,256 ? 0,169  ms/op

src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java line 167:

> 165:         return dst.getColorModel().hasAlpha() == src.getColorModel().hasAlpha();
> 166:     }
> 167: 

Thoughts about the method above:
 - I have left the first check as-is, so for any opaque destinations we will pass data to the lcms directly, but I am not sure that this is correct for source/destination with premultiplied alpha.
 - Since I am not sure about premultiplied alpha I have excluded it for the current fix if the destination has an alpha channel.

src/java.desktop/share/native/liblcms/LCMS.c line 193:

> 191: 
> 192:     sTrans = cmsCreateMultiprofileTransform(iccArray, j,
> 193:         inFormatter, outFormatter, renderType, cmsFLAGS_COPY_ALPHA);

Does not affect performance if the image does not have alpha.

test/jdk/sun/java2d/cmm/ColorConvertOp/ColCvtAlphaDifferentSrcDst.java line 73:

> 71:         //opaqueDst(TYPE_INT_ARGB_PRE, TYPE_4BYTE_ABGR_PRE);
> 72:         //opaqueDst(TYPE_4BYTE_ABGR_PRE, TYPE_INT_BGR);
> 73:     }

Actually, according to the spec, we should transform pre-alpha to alpha -> then apply ICC transform -> then transform pre-alpha-> alpha.
See class description of the:
https://docs.oracle.com/javase/7/docs/api/java/awt/image/ColorConvertOp.html

But it looks like implementation does something different.

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

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

From philip.race at oracle.com  Tue Mar 30 05:33:36 2021
From: philip.race at oracle.com (Philip Race)
Date: Mon, 29 Mar 2021 22:33:36 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> libfontmanager.so: undefined symbol:
 hb_font_destroy in openjdk17~14
In-Reply-To: <AzZ8fg.qBOdc5ZWgV8p.0OQlIBHpoxg77jWvfDZ@freemail.hu>
References: <AzYFXg.4TjS8FJQjjVL.IOrWRGrbuQBC6W2V2UQe@freemail.hu>
 <2548be46-db99-8242-c04c-ac98a939a6f0@oracle.com>
 <AzZ8fg.qBOdc5ZWgV8p.0OQlIBHpoxg77jWvfDZ@freemail.hu>
Message-ID: <0cca5a02-5dbb-4c2a-4720-945a64e06088@oracle.com>



On 3/29/21 8:14 PM, mc36 wrote:
> hi,
> please dont! i got ~15 and the issue is gone!

please don't do what ?

> (but answering line by line, who knows)
> thanks,
> cs

Ok. So it looks like you are using some debian build of openjdk and it 
seems likely
it can't find the system libharfbuzz.so since that symbol is very basic.

If you use the one from https://jdk.java.net/17/ I expect it will work 
since it does
what the JDK 15 does that I suggested.

I can't tell what the JDK 16 you have does since I'd need to see an ls 
-l of your
/lib/jvm/java-16-openjdk-amd64/lib/libfontmanager.so

-phil.

>
>
> On 3/29/21 6:41 PM, Philip Race wrote:
>> Moving this to the right list.
>>
>> There's lots of missing information in your email.
>>
>> 1) I don't know what a debian sid is. Internet suggests it is some 
>> upstream dev version
>> Is this reproducible on any shipping distro ?
> yesss, it is. https://www.debian.org/
> the only difference that you replace stable to 
> unstable/sid/experimental,depending how brave you're.... :)
>
>>
>> 2) Where exactly did you get the openjdk build 17 ? Was it from 
>> https://jdk.java.net/17/ or somewhere else ?
>> Please show the output of "java -version" to help confirm it.
>
> sudo apt install openjdk-17-jre -- to get the latest build of them....
> at the moment i see the following version:
>
> mc36 at noti:~$ java -version
> openjdk version "17-ea" 2021-09-14
> OpenJDK Runtime Environment (build 17-ea+15-Debian-1)
> OpenJDK 64-Bit Server VM (build 17-ea+15-Debian-1, mixed mode, sharing)
> mc36 at noti:~$
>
>>
>> 3) What does?? "ls -l lib/libfontmanager.so" show ?
>
> mc36 at noti:~$ find /lib/ -name libfontmanager.so
> /lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libfontmanager.so
> /lib/jvm/java-15-openjdk-amd64/lib/libfontmanager.so
> /lib/jvm/java-16-openjdk-amd64/lib/libfontmanager.so
> /lib/jvm/java-13-openjdk-amd64/lib/libfontmanager.so
> /lib/jvm/java-11-openjdk-amd64/lib/libfontmanager.so
> /lib/jvm/java-14-openjdk-amd64/lib/libfontmanager.so
> /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
> mc36 at noti:~$ ls -lsa /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
> 56 -rw-r--r-- 1 root root 55960 Mar 25 10:31 
> /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
> mc36 at noti:~$
>
>
>> 4) What was the JDK version you had immediately before this and where 
>> did you get that ?
> i have all that is available in the distro, but it depends, my older 
> installations have something from java6 times :)
>
>> 5) Does either JDK 11u or JDK15u work in this respect on that system ?
>
> yesss, right now, every installed jvm works perfectly, i olny saw the 
> issue with 17~14!!!!
> then, for a while i sudo update-alternatives --config java 'ed to 16, 
> but when they bumped
> to ~15, the i reverted to auto, that is 17, and the issue is 
> completely gone, now all the
> jvms i have works fine!
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210329/80eb524e/attachment.htm>

From swpalmer at gmail.com  Fri Mar 12 04:00:11 2021
From: swpalmer at gmail.com (Scott Palmer)
Date: Fri, 12 Mar 2021 04:00:11 -0000
Subject: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS
 Rendering Pipeline [v13]
In-Reply-To: <ZIHvDdoUouMeLdECi794Mflyc_dEX0cUFnEO1M6Bv7U=.a8c7959f-1766-4239-afb8-26b5848c7365@github.com>
References: <ZIHvDdoUouMeLdECi794Mflyc_dEX0cUFnEO1M6Bv7U=.a8c7959f-1766-4239-afb8-26b5848c7365@github.com>
Message-ID: <5BB55AA4-04ED-4B6B-BB89-61DDD5D7EB53@gmail.com>


> On Mar 11, 2021, at 9:53 PM, Sergey Bylokhov <serb at openjdk.java.net> wrote:
> 
> ?On Fri, 12 Mar 2021 02:29:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:
> 
>>> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 323:
>>> 
>>>> 321:      * more code just to support a few uncommon cases.
>>>> 322:      */
>>>> 323:     public boolean canRenderLCDText(SunGraphics2D sg2d) {
>>> 
>>> Just curious, can we render LCD on 10.14+ via metal? Does it work fine?
>> 
>> Yes Sergey it works fine in 10.14+ systems via metal. Most of the JCK manual tests use LCD text on UI Components and it is recently verified in 10.14+ systems for EA10.
> 
> Ok, for some reason I thought that the new macOS stopped providing LCD glyphs.
> 

Are the glyphs different or just the way they are rasterized?

Newer versions of macOS don?t do LCD text and have gone back to plain grey-scale anti-aliasing. 
Java 2D should default to NOT doing LCD anti-aliasing for text on macOS if it wants to fit in with the look of native applications. 
(I?m not sure if that applies to non-retina displays.)

Scott 

From mc36 at freemail.hu  Tue Mar 30 03:14:21 2021
From: mc36 at freemail.hu (mc36)
Date: Tue, 30 Mar 2021 05:14:21 +0200 (CEST)
Subject: [OpenJDK 2D-Dev] <AWT Dev> libfontmanager.so: undefined symbol:
 hb_font_destroy in openjdk17~14
In-Reply-To: <2548be46-db99-8242-c04c-ac98a939a6f0@oracle.com>
References: <AzYFXg.4TjS8FJQjjVL.IOrWRGrbuQBC6W2V2UQe@freemail.hu>
 <2548be46-db99-8242-c04c-ac98a939a6f0@oracle.com>
Message-ID: <AzZ8fg.qBOdc5ZWgV8p.0OQlIBHpoxg77jWvfDZ@freemail.hu>

hi,
please dont! i got ~15 and the issue is gone!
(but answering line by line, who knows)
thanks,
cs


On 3/29/21 6:41 PM, Philip Race wrote:
Moving this to the right list.

There's lots of missing information in your email.

1) I don't know what a debian sid is. Internet suggests it is some upstream dev version
Is this reproducible on any shipping distro ?
yesss, it is. https://www.debian.org/
the only difference that you replace stable to unstable/sid/experimental,depending how brave you're.... :)

?

2) Where exactly did you get the openjdk build 17 ? Was it from https://jdk.java.net/17/ or somewhere else ?
Please show the output of "java -version" to help confirm it.

sudo apt install openjdk-17-jre -- to get the latest build of them....
at the moment i see the following version:

mc36 at noti:~$ java -version
openjdk version "17-ea" 2021-09-14
OpenJDK Runtime Environment (build 17-ea+15-Debian-1)
OpenJDK 64-Bit Server VM (build 17-ea+15-Debian-1, mixed mode, sharing)
mc36 at noti:~$

?

3) What does?? "ls -l lib/libfontmanager.so" show ?
?

mc36 at noti:~$ find /lib/ -name libfontmanager.so
/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libfontmanager.so
/lib/jvm/java-15-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-16-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-13-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-11-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-14-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
mc36 at noti:~$ ls -lsa /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
56 -rw-r--r-- 1 root root 55960 Mar 25 10:31 /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
mc36 at noti:~$


?
4) What was the JDK version you had immediately before this and where did you get that ?
?
i have all that is available in the distro, but it depends, my older installations have something from java6 times :)

?
5) Does either JDK 11u or JDK15u work in this respect on that system ?
?

yesss, right now, every installed jvm works perfectly, i olny saw the issue with 17~14!!!!
then, for a while i sudo update-alternatives --config java 'ed to 16, but when they bumped
to ~15, the i reverted to auto, that is 17, and the issue is completely gone, now all the
jvms i have works fine!


?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210330/8c0d62d8/attachment-0001.htm>

From github.com+10835776+stsypanov at openjdk.java.net  Tue Mar 30 06:52:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 30 Mar 2021 06:52:43 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8263560: Remove needless wrapping with
 BufferedInputStream
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <c6tIF-4jWFv4iLkJPlKq7ABPqw2f_gCnrflDqE6AxwQ=.6187aee6-098b-4ab3-83d8-e7fcb289b015@github.com>

On Sat, 13 Mar 2021 22:29:23 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

This pull request has now been integrated.

Changeset: 1a681fa7
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1a681fa7
Stats:     12 lines in 2 files changed: 2 ins; 5 del; 5 mod

8263560: Remove needless wrapping with BufferedInputStream

Reviewed-by: prr, alanb, dfuchs, serb

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

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

From shade at openjdk.java.net  Tue Mar 30 13:02:33 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Mar 2021 13:02:33 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264428: Replace uses of StringBuffer
 with StringBuilder in java.desktop
In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
Message-ID: <OYj2953f0x9pdKEhuSH42Z6esy3iynF4-3F9WZA8EO0=.0c964e47-3802-45b3-9839-17e358981868@github.com>

On Mon, 29 Mar 2021 20:50:14 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

Submitted: https://bugs.openjdk.java.net/browse/JDK-8264428, please rename PR to "8264428: Replace uses of StringBuffer with StringBuilder in java.desktop".

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 30 13:02:32 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 30 Mar 2021 13:02:32 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264428: Replace uses of StringBuffer with
 StringBuilder in java.desktop
Message-ID: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>

Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

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

Commit messages:
 - [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/3251/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3251&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264428
  Stats: 44 lines in 11 files changed: 0 ins; 8 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3251.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3251/head:pull/3251

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 30 18:34:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 30 Mar 2021 18:34:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264428: Replace uses of StringBuffer
 with StringBuilder in java.desktop
In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
Message-ID: <HMCzNL_mAseqa95XZS9iKIG6K6ecqtxxWAVUDtKv8gI=.4aa9b5bd-495d-4488-821d-2ebd1c77cdcb@github.com>

On Mon, 29 Mar 2021 20:50:14 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFFieldNode.java line 127:

> 125:                 StringBuilder sb = new StringBuilder();
> 126:                 for (int i = 0; i < count; i++) {
> 127:                     sb.append((data[i] & 0xff));

Remove redundant parentheses

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 30 19:05:37 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 30 Mar 2021 19:05:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264428: Replace uses of StringBuffer
 with StringBuilder in java.desktop [v2]
In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
Message-ID: <YjutOPE7zU7j6mJgKHbFBZXDVijxc7dQvabEPdPhHHU=.def4ecf3-5d0f-4885-8331-9695a6cbee89@github.com>

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3251/files
  - new: https://git.openjdk.java.net/jdk/pull/3251/files/9bd4e523..80bff1db

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 30 19:05:38 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 30 Mar 2021 19:05:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264428: Replace uses of StringBuffer
 with StringBuilder in java.desktop [v2]
In-Reply-To: <HMCzNL_mAseqa95XZS9iKIG6K6ecqtxxWAVUDtKv8gI=.4aa9b5bd-495d-4488-821d-2ebd1c77cdcb@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
 <HMCzNL_mAseqa95XZS9iKIG6K6ecqtxxWAVUDtKv8gI=.4aa9b5bd-495d-4488-821d-2ebd1c77cdcb@github.com>
Message-ID: <sr4g3rzUpV-N1GUFK5Ips4ZZ5KAUJGw0BvnkaXdepbQ=.98f7e224-64bc-46ac-baaa-6430a92130bf@github.com>

On Tue, 30 Mar 2021 18:31:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFFieldNode.java line 127:
> 
>> 125:                 StringBuilder sb = new StringBuilder();
>> 126:                 for (int i = 0; i < count; i++) {
>> 127:                     sb.append((data[i] & 0xff));
> 
> Remove redundant parentheses

fixed.
It's suspicious that IDEA wasn't able to remove them by itself. Reported https://youtrack.jetbrains.com/issue/IDEA-265548

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

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

From philip.race at oracle.com  Tue Mar 30 23:34:15 2021
From: philip.race at oracle.com (Philip Race)
Date: Tue, 30 Mar 2021 16:34:15 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> libfontmanager.so: undefined symbol:
 hb_font_destroy in openjdk17~14
In-Reply-To: <0cca5a02-5dbb-4c2a-4720-945a64e06088@oracle.com>
References: <AzYFXg.4TjS8FJQjjVL.IOrWRGrbuQBC6W2V2UQe@freemail.hu>
 <2548be46-db99-8242-c04c-ac98a939a6f0@oracle.com>
 <AzZ8fg.qBOdc5ZWgV8p.0OQlIBHpoxg77jWvfDZ@freemail.hu>
 <0cca5a02-5dbb-4c2a-4720-945a64e06088@oracle.com>
Message-ID: <8aa59b9f-428e-c3f6-66bd-3466fbe0a61a@oracle.com>

PS also I'd be interested to know the output of
ldd /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so

It should resolve libharfbuzz.so in some system directory

I've double-checked the test build I did on Ubuntu 20.10 for JDK 17 b14 
and it works fine
finding libharfbuzz there.

So my current best guess is it is related to how your distro built it ..


-phil.



On 3/29/21 10:33 PM, Philip Race wrote:
>
>
> On 3/29/21 8:14 PM, mc36 wrote:
>> hi,
>> please dont! i got ~15 and the issue is gone!
>
> please don't do what ?
>
>> (but answering line by line, who knows)
>> thanks,
>> cs
>
> Ok. So it looks like you are using some debian build of openjdk and it 
> seems likely
> it can't find the system libharfbuzz.so since that symbol is very basic.
>
> If you use the one from https://jdk.java.net/17/ I expect it will work 
> since it does
> what the JDK 15 does that I suggested.
>
> I can't tell what the JDK 16 you have does since I'd need to see an ls 
> -l of your
> /lib/jvm/java-16-openjdk-amd64/lib/libfontmanager.so
>
> -phil.
>
>>
>>
>> On 3/29/21 6:41 PM, Philip Race wrote:
>>> Moving this to the right list.
>>>
>>> There's lots of missing information in your email.
>>>
>>> 1) I don't know what a debian sid is. Internet suggests it is some 
>>> upstream dev version
>>> Is this reproducible on any shipping distro ?
>> yesss, it is. https://www.debian.org/
>> the only difference that you replace stable to 
>> unstable/sid/experimental,depending how brave you're.... :)
>>
>>>
>>> 2) Where exactly did you get the openjdk build 17 ? Was it from 
>>> https://jdk.java.net/17/ or somewhere else ?
>>> Please show the output of "java -version" to help confirm it.
>>
>> sudo apt install openjdk-17-jre -- to get the latest build of them....
>> at the moment i see the following version:
>>
>> mc36 at noti:~$ java -version
>> openjdk version "17-ea" 2021-09-14
>> OpenJDK Runtime Environment (build 17-ea+15-Debian-1)
>> OpenJDK 64-Bit Server VM (build 17-ea+15-Debian-1, mixed mode, sharing)
>> mc36 at noti:~$
>>
>>>
>>> 3) What does?? "ls -l lib/libfontmanager.so" show ?
>>
>> mc36 at noti:~$ find /lib/ -name libfontmanager.so
>> /lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libfontmanager.so
>> /lib/jvm/java-15-openjdk-amd64/lib/libfontmanager.so
>> /lib/jvm/java-16-openjdk-amd64/lib/libfontmanager.so
>> /lib/jvm/java-13-openjdk-amd64/lib/libfontmanager.so
>> /lib/jvm/java-11-openjdk-amd64/lib/libfontmanager.so
>> /lib/jvm/java-14-openjdk-amd64/lib/libfontmanager.so
>> /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
>> mc36 at noti:~$ ls -lsa /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
>> 56 -rw-r--r-- 1 root root 55960 Mar 25 10:31 
>> /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
>> mc36 at noti:~$
>>
>>
>>> 4) What was the JDK version you had immediately before this and 
>>> where did you get that ?
>> i have all that is available in the distro, but it depends, my older 
>> installations have something from java6 times :)
>>
>>> 5) Does either JDK 11u or JDK15u work in this respect on that system ?
>>
>> yesss, right now, every installed jvm works perfectly, i olny saw the 
>> issue with 17~14!!!!
>> then, for a while i sudo update-alternatives --config java 'ed to 16, 
>> but when they bumped
>> to ~15, the i reverted to auto, that is 17, and the issue is 
>> completely gone, now all the
>> jvms i have works fine!
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210330/f7b7d795/attachment-0001.htm>

From jdv at openjdk.java.net  Wed Mar 31 07:34:42 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 31 Mar 2021 07:34:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal
 rendering pipeline
Message-ID: <I0A8W-OrfzYfDMEjkgUb2dEsbJF9QH8G9p2lv5KmzDQ=.db973127-37ab-4e48-b1a5-d4e87805e7f9@github.com>

In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea.

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

Commit messages:
 - 8264475: CopyArea ignores clip state in metal rendering pipeline

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

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

From jdv at openjdk.java.net  Wed Mar 31 07:34:42 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 31 Mar 2021 07:34:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in
 metal rendering pipeline
In-Reply-To: <I0A8W-OrfzYfDMEjkgUb2dEsbJF9QH8G9p2lv5KmzDQ=.db973127-37ab-4e48-b1a5-d4e87805e7f9@github.com>
References: <I0A8W-OrfzYfDMEjkgUb2dEsbJF9QH8G9p2lv5KmzDQ=.db973127-37ab-4e48-b1a5-d4e87805e7f9@github.com>
Message-ID: <sJqIb98kTFy5FeXEikTL-S0_lVApG7bBb6g4lAcATI0=.6876e1fa-e9c0-4151-91a7-1870fb8f5e2f@github.com>

On Wed, 31 Mar 2021 07:27:45 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m line 206:

> 204:                                                            mipmapped:NO];
> 205:     textureDescriptor.usage = MTLTextureUsageRenderTarget |
> 206:         MTLTextureUsageShaderRead;

In copyArea we use intermediate texture queried from TexturePool as render target. If we dont set any MTLTextureUsage, we are getting assertion errors when Metal API validation is enabled because by default we can only do texture shader read(https://developer.apple.com/documentation/metal/mtltexturedescriptor/1515783-usage?language=objc). To avoid these assertion errors in Metal API validation we need to set appropriate MTLTextureUsage parameters.

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

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

From aghaisas at openjdk.java.net  Wed Mar 31 12:43:17 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 31 Mar 2021 12:43:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in
 metal rendering pipeline
In-Reply-To: <I0A8W-OrfzYfDMEjkgUb2dEsbJF9QH8G9p2lv5KmzDQ=.db973127-37ab-4e48-b1a5-d4e87805e7f9@github.com>
References: <I0A8W-OrfzYfDMEjkgUb2dEsbJF9QH8G9p2lv5KmzDQ=.db973127-37ab-4e48-b1a5-d4e87805e7f9@github.com>
Message-ID: <1Iq_SFdZn90BWHWlLdfPP0YWcUABM-TtG_yun_E8L-8=.cd2878ec-d567-4afd-a2a9-5a30dd493e10@github.com>

On Wed, 31 Mar 2021 07:27:45 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea.

I tested this fix. No regressions were observed.

Using MTLBlitCommandEncoder is intuitive when metal resource copying needs to be done.
I suggest to add a comment (may be as a method description or in code where we do the actual copy) to mention why we use MTLRenderCommandEncoder and not MTLBlitCommandEncoder.

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

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

From philip.race at oracle.com  Wed Mar 31 14:41:40 2021
From: philip.race at oracle.com (Philip Race)
Date: Wed, 31 Mar 2021 07:41:40 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> libfontmanager.so: undefined symbol:
 hb_font_destroy in openjdk17~14
In-Reply-To: <AzaJRw.nIsJNaLn9rdG.rVBwu3YswwMuaWmCWIju@freemail.hu>
References: <AzYFXg.4TjS8FJQjjVL.IOrWRGrbuQBC6W2V2UQe@freemail.hu>
 <2548be46-db99-8242-c04c-ac98a939a6f0@oracle.com>
 <AzZ8fg.qBOdc5ZWgV8p.0OQlIBHpoxg77jWvfDZ@freemail.hu>
 <0cca5a02-5dbb-4c2a-4720-945a64e06088@oracle.com>
 <8aa59b9f-428e-c3f6-66bd-3466fbe0a61a@oracle.com>
 <AzaJRw.nIsJNaLn9rdG.rVBwu3YswwMuaWmCWIju@freemail.hu>
Message-ID: <2f5c1162-7add-ff31-d24c-ed49a6cad7cf@oracle.com>



On 3/30/21 11:31 PM, mc36 wrote:
>
> please find below, but, again, it's jre17~15, where everything seems fine.

Oh that's what you mean by the incomprehensible
" please dont! i got ~15 and the issue is gone!"

So it was some one-off problem with the build 14 from your distro.

I think this points to how important it is to first complain there and 
not here.

-phil.

From jdv at openjdk.java.net  Wed Mar 31 15:03:54 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 31 Mar 2021 15:03:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in
 metal rendering pipeline [v2]
In-Reply-To: <I0A8W-OrfzYfDMEjkgUb2dEsbJF9QH8G9p2lv5KmzDQ=.db973127-37ab-4e48-b1a5-d4e87805e7f9@github.com>
References: <I0A8W-OrfzYfDMEjkgUb2dEsbJF9QH8G9p2lv5KmzDQ=.db973127-37ab-4e48-b1a5-d4e87805e7f9@github.com>
Message-ID: <KJdX0UL0EshTT7R78BIgPs84OxVZcBI0DnzQeeu_qkY=.3f144134-615a-4a57-b10c-effbe40662e0@github.com>

> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Add comment on usage of MTLRenderCommandEncoder

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3283/files
  - new: https://git.openjdk.java.net/jdk/pull/3283/files/d72f9490..3e1ba4c9

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

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

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

From jdv at openjdk.java.net  Wed Mar 31 15:06:27 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 31 Mar 2021 15:06:27 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in
 metal rendering pipeline
In-Reply-To: <1Iq_SFdZn90BWHWlLdfPP0YWcUABM-TtG_yun_E8L-8=.cd2878ec-d567-4afd-a2a9-5a30dd493e10@github.com>
References: <I0A8W-OrfzYfDMEjkgUb2dEsbJF9QH8G9p2lv5KmzDQ=.db973127-37ab-4e48-b1a5-d4e87805e7f9@github.com>
 <1Iq_SFdZn90BWHWlLdfPP0YWcUABM-TtG_yun_E8L-8=.cd2878ec-d567-4afd-a2a9-5a30dd493e10@github.com>
Message-ID: <86-OA0614MggDHTo2H9Sap5OlbQvXgKus1E8dKRrYUU=.c400d0ef-77f3-4e4a-8f67-a683241458e7@github.com>

On Wed, 31 Mar 2021 12:39:49 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> I tested this fix. No regressions were observed.
> 
> Using MTLBlitCommandEncoder is intuitive when metal resource copying needs to be done.
> I suggest to add a comment (may be as a method description or in code where we do the actual copy) to mention why we use MTLRenderCommandEncoder and not MTLBlitCommandEncoder.

Thanks Ajit for testing the fix. I have added comment mentioning why we use MTLRenderCommandEncoder and not MTLBlitCommandEncoder.

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

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

From azvegint at openjdk.java.net  Wed Mar 31 17:58:15 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 31 Mar 2021 17:58:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8012229: [lcms] Improve performance of
 color conversion for images with alpha channel
In-Reply-To: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>
References: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>
Message-ID: <DoHI0UXDs-qJ8viXuA_Qnw3jS2EAS_aRF2bxtV16ckA=.82b21e3f-8151-41d7-a721-95eaf1b742c1@github.com>

On Mon, 29 Mar 2021 07:36:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The lcms 2.8 version added support for the cmsFLAGS_COPY_ALPHA flag:
> https://sourceforge.net/p/lcms/mailman/lcms-user/thread/001c01d1c0f3%2484a7cb30%248df76190%24%40ProDigitalSoftware.com/#msg35143398
> 
> which supports alpha channel transportation
> 
> For our usage, it means we can use TYPE_4BYTE_ABGR and TYPE_INT_ARGB directly as a source and destination.
> 
> Some numbers:
> converting new BufferedImage(3000, 3000, TYPE_INT_ARGB) from CS_sRGB to CS_CIEXYZ via op.filter(src, dst).
> //before the fix
> //Benchmark                  Mode  Cnt    Score    Error  Units
> //ColorAlphaConv.testFilter  avgt    5  603,392 ? 12,932  ms/op
> 
> //after the fix
> //Benchmark                  Mode  Cnt    Score   Error  Units
> //ColorAlphaConv.testFilter  avgt    5  121,624 ? 0,906  ms/op
> 
> But still slower than kcms
> //kcms jdk8u60
> //Benchmark                  Mode  Cnt   Score   Error  Units
> //ColorAlphaConv.testFilter  avgt    5  13,256 ? 0,169  ms/op

Marked as reviewed by azvegint (Reviewer).

test/jdk/sun/java2d/cmm/ColorConvertOp/ColCvtAlphaDifferentSrcDst.java line 52:

> 50: 
> 51:     private static int WIDTH = 256;
> 52:     private static int HEIGHT = 256;

Basing on naming, it looks that you wanted to make these variable final.

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

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

From aivanov at openjdk.java.net  Wed Mar 31 19:47:24 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 31 Mar 2021 19:47:24 GMT
Subject: [OpenJDK 2D-Dev] Withdrawn: 8263893: getPrinterNames() leaks
 nameArray if Java String allocation fails
In-Reply-To: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
References: <qx9k6mv2foJS9y9NuHEa-4li-mJF--IHLRF8_iygWpU=.9d0f1cbe-6e41-465d-8fb4-f23c7b56228b@github.com>
Message-ID: <Da62uYRmY7p7AfFXyWj1LapHNazypmaCttxqSFU6veI=.e293963b-8b04-4310-9b5f-01727a9370a5@github.com>

On Fri, 19 Mar 2021 20:36:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> If `JNU_NewStringPlatform` fails to allocate new Java String object for printer name, `std::bad_alloc` is thrown. The handler for the exception does not release the local reference to the `nameArray`, thus it will be leaked.

This pull request has been closed without being integrated.

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

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

From serb at openjdk.java.net  Wed Mar 31 19:59:25 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 19:59:25 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262470: Printed GlyphVector outline with
 low DPI has bad quality on Windows [v2]
In-Reply-To: <Pv-3othcHkeCmAzzT4N-Yo6PgpSZDvWKpTAv64eMrlg=.db259733-c420-4ff7-8a66-284ce87994c0@github.com>
References: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>
 <Pv-3othcHkeCmAzzT4N-Yo6PgpSZDvWKpTAv64eMrlg=.db259733-c420-4ff7-8a66-284ce87994c0@github.com>
Message-ID: <sMgpTYGk8M8S5UMbOHgzVAGf4hnzK4j_IfCjI5epSS0=.a5e73c04-233c-42f1-a00a-e6a9cf8c5761@github.com>

On Thu, 18 Mar 2021 12:29:01 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
>> The GDI system used for text printing on Windows accepts only integer path coordinates.
>> Rounding GlyphVector outline coordinates leads to distorted printed text.
>> 
>> The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page".
>> 
>> The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.
>> 
>> The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.
>> 
>> I tried to put wPrinterJob.beginPath()/endPath()  methods around wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape.
>> 
>> The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method.
>> The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() .
>> 
>> The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix.
>> 
>> There are two failed automated tests which fail without the fix as well:
>> java/awt/print/PrinterJob/GlyphPositions.java 
>> java/awt/print/PrinterJob/PSQuestionMark.java
>> 
>> The following manual tests have issues on my system:
>> - `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static"
>> 
>> - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons.
>> 
>> - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html
>> 
>> 
>> - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain  print/pass/fail buttons and it is not possible to close the window.
>> 
>> - The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message:
>> java/awt/print/Dialog/DialogOrient.java
>> java/awt/print/Dialog/DialogType.java
>> java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
>> java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
>> java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
>> java/awt/print/PrinterJob/PageDialogTest.java
>> java/awt/print/PrinterJob/PageRanges.java
>> java/awt/print/PrinterJob/PageRangesDlgTest.java
>> java/awt/print/PrinterJob/PrintGlyphVectorTest.java
>> java/awt/print/PrinterJob/PrintLatinCJKTest.java
>> java/awt/print/PrinterJob/PrintTextTest.java
>> java/awt/print/PrinterJob/SwingUIText.java
>> java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
>> java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
>> java/awt/PrintJob/SaveDialogTitleTest.java
>
> Alexander Scherbatiy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use DASSERT to check SetGraphicsMode and WorldTransform results
>  - Change setGraphicsMode() type to void

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Wed Mar 31 20:40:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 20:40:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm'
 in libjavajpeg and libawt
In-Reply-To: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com>
Message-ID: <ZX0Cm_wpwALoFrwdDcqLV1SzCvZa-4ejv4mR0WSftc8=.c4ebc256-061f-41a4-8f82-ff68b07fd8fa@github.com>

On Tue, 23 Mar 2021 15:18:13 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The suggestion is to rename 'jvm' variable in `libjavajpeg` to `the_jvm` so this conflict no longer occurs when `libjavajpeg.a` and `libawt.a` are being linked into one native image.
> 
> Testing: test/jdk/javax/imageio jtreg tests. GHA pre-integration tests running too.
> 
> Thoughts?

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Wed Mar 31 21:15:30 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 21:15:30 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264428: Replace uses of StringBuffer
 with StringBuilder in java.desktop
In-Reply-To: <OYj2953f0x9pdKEhuSH42Z6esy3iynF4-3F9WZA8EO0=.0c964e47-3802-45b3-9839-17e358981868@github.com>
References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com>
 <OYj2953f0x9pdKEhuSH42Z6esy3iynF4-3F9WZA8EO0=.0c964e47-3802-45b3-9839-17e358981868@github.com>
Message-ID: <27yKI-MoNpdtE7_qYEHLNj-tmphsEvwwT7NunRjEY5c=.d585ed9c-b74c-4b82-8c24-fca05d944f58@github.com>

On Tue, 30 Mar 2021 12:39:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
>> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.desktop`
>> Similar cleanups in the past: https://bugs.openjdk.java.net/browse/JDK-8041679 https://bugs.openjdk.java.net/browse/JDK-8264029
>
> Submitted: https://bugs.openjdk.java.net/browse/JDK-8264428, please rename PR to "8264428: Replace uses of StringBuffer with StringBuilder in java.desktop".

Looks like this change goes beyond of simple replacement of  StringBuffer with StringBuilder. Please update the description of the bug and PR description.

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

PR: https://git.openjdk.java.net/jdk/pull/3251

From serb at openjdk.java.net  Wed Mar 31 21:26:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 21:26:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need
 some specification clean up
In-Reply-To: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
References: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
Message-ID: <zeGZ2K03zg5e9QUm3Z_oIT1Ar1NtjtWdHBvFqDJ_B8o=.86e26c9e-0305-45c9-a958-5c82dc5f26a2@github.com>

On Fri, 26 Mar 2021 19:53:44 GMT, Phil Race <prr at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but
> it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation.
> I've spent a lot of time on what is just small number of factory methods in Raster because there are so
> many possible exceptions and in some cases they rely on other API they call to generate exceptions and
> these may have not been documented or documented acc. to some long lost behavior.
> I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that
> ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about
> always has to be an internal bug !
> 
> The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of
> cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17
> So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException
> to IllegalArgumentException.
> JCK conformance tests still pass so they must not test those conditions.

src/java.desktop/share/classes/java/awt/image/Raster.java line 263:

> 261:      *         both > 0
> 262:      * @throws IllegalArgumentException if the product of {@code w}
> 263:      *         and {@code h} is greater than {@code Integer.MAX_VALUE}

Do we really want to specify this? I hit this bug during HiDPI work and it seems this is an implementation bug that we do not support big size(w*h).

src/java.desktop/share/classes/java/awt/image/Raster.java line 337:

> 335:      *         {@code DataBuffer.TYPE_BYTE},
> 336:      *         {@code DataBuffer.TYPE_USHORT}
> 337:      *         or {@code DataBuffer.TYPE_INT}

What about other types like TYPE_SHORT or we assume it is unsupported?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3223

From serb at openjdk.java.net  Wed Mar 31 21:26:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 21:26:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need
 some specification clean up
In-Reply-To: <vh5oLb4ErHoJRLEgNBwqej0Gnqyq974K7ZWPib1Koq8=.62f4a56a-03e2-47c1-988e-2399afd8ceca@github.com>
References: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
 <-0wFDhzgacQic6ii8fKr9N3HLDcQi5AjF-sNNznUGxg=.dabe42bd-2f95-4f12-be90-2a4a35be3234@github.com>
 <vh5oLb4ErHoJRLEgNBwqej0Gnqyq974K7ZWPib1Koq8=.62f4a56a-03e2-47c1-988e-2399afd8ceca@github.com>
Message-ID: <I9rGzK_xX--_G-D7fAtEJ0JeBtOwRIr9vDMrx4S5Nug=.f28d2d8c-ab91-444f-9b52-2533547211df@github.com>

On Fri, 26 Mar 2021 22:45:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java line 127:
>> 
>>> 125:      * @throws IllegalArgumentException if {@code pixelStride} is less than 0
>>> 126:      * @throws IllegalArgumentException if {@code scanlineStride} is less than 0
>>> 127:      * @throws NullPointerException if {@code bandOffsets} is {@code null}
>> 
>> I like the NPE here, but probably it makes sense to use the same exception for all errors? "IllegalArgumentException "
>
> Meaning even though you like the NPE you would change it to IAE like the rest ?

Yes and no, I just wanted to highlight this place, since somebody may prefer IAE here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3223

From serb at openjdk.java.net  Wed Mar 31 21:31:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 21:31:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8012229: [lcms] Improve performance of
 color conversion for images with alpha channel [v2]
In-Reply-To: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>
References: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>
Message-ID: <Q13xvA_bH2I96HqhrZiv6VdspN5T-zpSW9ha1zkns5c=.c8e0adef-1591-4d9c-be44-d6099b3cd361@github.com>

> The lcms 2.8 version added support for the cmsFLAGS_COPY_ALPHA flag:
> https://sourceforge.net/p/lcms/mailman/lcms-user/thread/001c01d1c0f3%2484a7cb30%248df76190%24%40ProDigitalSoftware.com/#msg35143398
> 
> which supports alpha channel transportation
> 
> For our usage, it means we can use TYPE_4BYTE_ABGR and TYPE_INT_ARGB directly as a source and destination.
> 
> Some numbers:
> converting new BufferedImage(3000, 3000, TYPE_INT_ARGB) from CS_sRGB to CS_CIEXYZ via op.filter(src, dst).
> //before the fix
> //Benchmark                  Mode  Cnt    Score    Error  Units
> //ColorAlphaConv.testFilter  avgt    5  603,392 ? 12,932  ms/op
> 
> //after the fix
> //Benchmark                  Mode  Cnt    Score   Error  Units
> //ColorAlphaConv.testFilter  avgt    5  121,624 ? 0,906  ms/op
> 
> But still slower than kcms
> //kcms jdk8u60
> //Benchmark                  Mode  Cnt   Score   Error  Units
> //ColorAlphaConv.testFilter  avgt    5  13,256 ? 0,169  ms/op

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8012229
 - Update ColCvtAlphaDifferentSrcDst.java
 - Initial fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3239/files
  - new: https://git.openjdk.java.net/jdk/pull/3239/files/c89a4ca1..60a3dfca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3239&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3239&range=00-01

  Stats: 4586 lines in 234 files changed: 3018 ins; 664 del; 904 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3239.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3239/head:pull/3239

PR: https://git.openjdk.java.net/jdk/pull/3239

From azvegint at openjdk.java.net  Wed Mar 31 21:37:26 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Wed, 31 Mar 2021 21:37:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8012229: [lcms] Improve performance of
 color conversion for images with alpha channel [v2]
In-Reply-To: <Q13xvA_bH2I96HqhrZiv6VdspN5T-zpSW9ha1zkns5c=.c8e0adef-1591-4d9c-be44-d6099b3cd361@github.com>
References: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>
 <Q13xvA_bH2I96HqhrZiv6VdspN5T-zpSW9ha1zkns5c=.c8e0adef-1591-4d9c-be44-d6099b3cd361@github.com>
Message-ID: <NVh9lbu7i_Qzqmj0-NAjSn3qAVPKGBumT1GEMAl1Lzk=.6f6ad594-9db5-482c-95c6-81de7d6f3186@github.com>

On Wed, 31 Mar 2021 21:31:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The lcms 2.8 version added support for the cmsFLAGS_COPY_ALPHA flag:
>> https://sourceforge.net/p/lcms/mailman/lcms-user/thread/001c01d1c0f3%2484a7cb30%248df76190%24%40ProDigitalSoftware.com/#msg35143398
>> 
>> which supports alpha channel transportation
>> 
>> For our usage, it means we can use TYPE_4BYTE_ABGR and TYPE_INT_ARGB directly as a source and destination.
>> 
>> Some numbers:
>> converting new BufferedImage(3000, 3000, TYPE_INT_ARGB) from CS_sRGB to CS_CIEXYZ via op.filter(src, dst).
>> //before the fix
>> //Benchmark                  Mode  Cnt    Score    Error  Units
>> //ColorAlphaConv.testFilter  avgt    5  603,392 ? 12,932  ms/op
>> 
>> //after the fix
>> //Benchmark                  Mode  Cnt    Score   Error  Units
>> //ColorAlphaConv.testFilter  avgt    5  121,624 ? 0,906  ms/op
>> 
>> But still slower than kcms
>> //kcms jdk8u60
>> //Benchmark                  Mode  Cnt   Score   Error  Units
>> //ColorAlphaConv.testFilter  avgt    5  13,256 ? 0,169  ms/op
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8012229
>  - Update ColCvtAlphaDifferentSrcDst.java
>  - Initial fix

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3239

From prr at openjdk.java.net  Wed Mar 31 22:06:18 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 31 Mar 2021 22:06:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need
 some specification clean up
In-Reply-To: <zeGZ2K03zg5e9QUm3Z_oIT1Ar1NtjtWdHBvFqDJ_B8o=.86e26c9e-0305-45c9-a958-5c82dc5f26a2@github.com>
References: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
 <zeGZ2K03zg5e9QUm3Z_oIT1Ar1NtjtWdHBvFqDJ_B8o=.86e26c9e-0305-45c9-a958-5c82dc5f26a2@github.com>
Message-ID: <QUYqiu_kQLj5LPekov7bfqAg8AY5eDxWkwm130n84yo=.50e0b18f-df36-4729-8934-49d162dd37e2@github.com>

On Wed, 31 Mar 2021 21:21:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but
>> it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation.
>> I've spent a lot of time on what is just small number of factory methods in Raster because there are so
>> many possible exceptions and in some cases they rely on other API they call to generate exceptions and
>> these may have not been documented or documented acc. to some long lost behavior.
>> I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that
>> ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about
>> always has to be an internal bug !
>> 
>> The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of
>> cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17
>> So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException
>> to IllegalArgumentException.
>> JCK conformance tests still pass so they must not test those conditions.
>
> src/java.desktop/share/classes/java/awt/image/Raster.java line 263:
> 
>> 261:      *         both > 0
>> 262:      * @throws IllegalArgumentException if the product of {@code w}
>> 263:      *         and {@code h} is greater than {@code Integer.MAX_VALUE}
> 
> Do we really want to specify this? I hit this bug during HiDPI work and it seems this is an implementation bug that we do not support big size(w*h).

The implementation issues that constrain this are substantial.
I find it unlikely we'd find a reason to support it.
I mean a bigger issue is we can'r even support an image that's Integer.MAX_VALUE wide and 1 pixel high.

Removing this from the spec. at that time would be trivial compared to the work in supporting it.
And likely it would be some other method that would support that anyway for the aforementioned int reason.
And we also (and always have) documented an exception if adding the location.x + w would overflow an int. 
So in summary, yes, let's document it.

> src/java.desktop/share/classes/java/awt/image/Raster.java line 337:
> 
>> 335:      *         {@code DataBuffer.TYPE_BYTE},
>> 336:      *         {@code DataBuffer.TYPE_USHORT}
>> 337:      *         or {@code DataBuffer.TYPE_INT}
> 
> What about other types like TYPE_SHORT or we assume it is unsupported?

The existing code throws IAE if it is not one of these exact types. See around line 460 in this updated file.
And that code is in a public factory method called by this factory method. And that callee has exactly this documentation. So I am just copying it over so that it is consistently documented.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3223

From prr at openjdk.java.net  Wed Mar 31 22:06:17 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 31 Mar 2021 22:06:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need
 some specification clean up
In-Reply-To: <I9rGzK_xX--_G-D7fAtEJ0JeBtOwRIr9vDMrx4S5Nug=.f28d2d8c-ab91-444f-9b52-2533547211df@github.com>
References: <tDBnwJ6uNS49ZdTl3aPolP5EdjQLjN0NKGnJshsc1QE=.08dab91e-1f24-4e57-9ce4-d6245024f7fa@github.com>
 <-0wFDhzgacQic6ii8fKr9N3HLDcQi5AjF-sNNznUGxg=.dabe42bd-2f95-4f12-be90-2a4a35be3234@github.com>
 <vh5oLb4ErHoJRLEgNBwqej0Gnqyq974K7ZWPib1Koq8=.62f4a56a-03e2-47c1-988e-2399afd8ceca@github.com>
 <I9rGzK_xX--_G-D7fAtEJ0JeBtOwRIr9vDMrx4S5Nug=.f28d2d8c-ab91-444f-9b52-2533547211df@github.com>
Message-ID: <Ix4gxdoq6hXbDFyYEi5wXtDnGeL3woa6LBYbmXNF7E0=.33f8bfdd-e66f-4fe2-9d55-651fc3c01f32@github.com>

On Wed, 31 Mar 2021 21:17:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Meaning even though you like the NPE you would change it to IAE like the rest ?
>
> Yes and no, I just wanted to highlight this place, since somebody may prefer IAE here.

Well IAE was my initial thought but I decided to minimize the behavioral changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3223

From serb at openjdk.java.net  Wed Mar 31 23:06:39 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 31 Mar 2021 23:06:39 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8012229: [lcms] Improve performance of
 color conversion for images with alpha channel
In-Reply-To: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>
References: <QK0TPz5K3R1JswGOL6Jogg60HE8yWGNvG62CApY5mxQ=.3060ae23-d17f-465b-a554-42c6337db51c@github.com>
Message-ID: <1W8FAmvukK1mGDPBnxIJ3TZy57eT1VjLn29bpmmUc98=.9561e5a8-5495-4ec0-8931-2e0da824a6ff@github.com>

On Mon, 29 Mar 2021 07:36:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The lcms 2.8 version added support for the cmsFLAGS_COPY_ALPHA flag:
> https://sourceforge.net/p/lcms/mailman/lcms-user/thread/001c01d1c0f3%2484a7cb30%248df76190%24%40ProDigitalSoftware.com/#msg35143398
> 
> which supports alpha channel transportation
> 
> For our usage, it means we can use TYPE_4BYTE_ABGR and TYPE_INT_ARGB directly as a source and destination.
> 
> Some numbers:
> converting new BufferedImage(3000, 3000, TYPE_INT_ARGB) from CS_sRGB to CS_CIEXYZ via op.filter(src, dst).
> //before the fix
> //Benchmark                  Mode  Cnt    Score    Error  Units
> //ColorAlphaConv.testFilter  avgt    5  603,392 ? 12,932  ms/op
> 
> //after the fix
> //Benchmark                  Mode  Cnt    Score   Error  Units
> //ColorAlphaConv.testFilter  avgt    5  121,624 ? 0,906  ms/op
> 
> But still slower than kcms
> //kcms jdk8u60
> //Benchmark                  Mode  Cnt   Score   Error  Units
> //ColorAlphaConv.testFilter  avgt    5  13,256 ? 0,169  ms/op

This pull request has now been integrated.

Changeset: 16acfafb
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/16acfafb
Stats:     208 lines in 5 files changed: 195 ins; 2 del; 11 mod

8012229: [lcms] Improve performance of color conversion for images with alpha channel

Reviewed-by: azvegint

-------------

PR: https://git.openjdk.java.net/jdk/pull/3239