From serb at openjdk.java.net  Sun Jan  3 03:28:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 3 Jan 2021 03:28:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException
In-Reply-To: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
Message-ID: <X5XnJic4tyYKEUQjJ_SuJMUjaGB_cEYEKJX4uCwuVh0=.dc9f5550-dd79-4272-a4d2-a02282a22d8b@github.com>

On Thu, 3 Dec 2020 23:52:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
> 
> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
> 
> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
> 
> Notes about the link above:
> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
> 
> The fix:
>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
> 
> See some comments inline.

Any volunteers for a review?

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 08:22:09 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 08:22:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
Message-ID: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>

Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.

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

Commit messages:
 - 8215537: [TEST_BUG] java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout

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

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

From serb at openjdk.java.net  Mon Jan  4 08:28:55 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Jan 2021 08:28:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
Message-ID: <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>

On Mon, 4 Jan 2021 08:15:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.

If the printer is not found then why the "PrinterException: No print service found" is not thrown?

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 08:47:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 08:47:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>
Message-ID: <iPVjSL9JFFydXE3NBHgQq3jiMpZ1rhPZKEYB2G74jso=.e2e4c94a-d15d-4258-9c8d-9f078eb08a0b@github.com>

On Mon, 4 Jan 2021 08:26:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.
>
> If the printer is not found then why the "PrinterException: No print service found" is not thrown?

IIUC, In windows there can be non-real printers like "Send To OneNote", "Fax" which falls in Printers/Scanner list but not exactly printer so PrinterException is not thrown.

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

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

From serb at openjdk.java.net  Mon Jan  4 09:26:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Jan 2021 09:26:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <iPVjSL9JFFydXE3NBHgQq3jiMpZ1rhPZKEYB2G74jso=.e2e4c94a-d15d-4258-9c8d-9f078eb08a0b@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>
 <iPVjSL9JFFydXE3NBHgQq3jiMpZ1rhPZKEYB2G74jso=.e2e4c94a-d15d-4258-9c8d-9f078eb08a0b@github.com>
Message-ID: <MeDghiRAR1ltL6XPZ42yo-D-_sDu_U7URPKy0UFE5ms=.753a74bd-6dc3-4c75-86f5-4e52dbad5383@github.com>

On Mon, 4 Jan 2021 08:45:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> IIUC, In windows there can be non-real printers like "Send To OneNote", "Fax" which falls in Printers/Scanner list but not exactly printer so PrinterException is not thrown.

I am not sure that the fax is related here, but the "printjob.print()" should throw such an exception if printjob.getPrintService() is null (so we do not have any useful printers). Do you have a chance to reproduce this bug?

BTW the suggestion in the JBS was to fail the test if no printers are found.

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

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

From psadhukhan at openjdk.java.net  Mon Jan  4 10:27:12 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 4 Jan 2021 10:27:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v2]
In-Reply-To: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
Message-ID: <7qjMCFOBix6UV1-FNgDfcBNkKvMXApGdA-f-9LvojRo=.c8334604-98f2-4baa-8a0b-abb171b6e1cf@github.com>

> Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fail the test if no printer is found

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1927/files
  - new: https://git.openjdk.java.net/jdk/pull/1927/files/4c3bc143..d4d70e34

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

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

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

From serb at openjdk.java.net  Mon Jan  4 11:22:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Jan 2021 11:22:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259042: Inconsistent use of general
 primitives loops
Message-ID: <Z0dnXH-TKnljzd11XC15CeXXyjOjLJpwdPIjP7cmH3g=.bbd2a121-f7b7-4913-8746-26c8cdbb01b8@github.com>

The java2d uses the primitives such as Blit loop for rendering differing things. Currently, not all possible variants of primitives are implemented, but it is possible to register some general loop that may produce the primitives for some specific src/comp/dst.

But we have some inconsistent here:
 - Some primitives register themselves as a general loop but always return null in the makePrimitive() method
 - Some primitives (which are not registered as general loops) return null or throw an error in the makePrimitive() method

After the fix:
 - The primitive will be registered as a general primitive only if it has a meaningful makePrimitive method
 - An attempt to call the makePrimitive for non registered general loop will cause an error

mach5 is green

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

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/1926/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1926&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259042
  Stats: 260 lines in 22 files changed: 33 ins; 167 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1926.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1926/head:pull/1926

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

From erikj at openjdk.java.net  Mon Jan  4 15:32:11 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 4 Jan 2021 15:32:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module [v4]
In-Reply-To: <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
Message-ID: <Pou_LYeQxlmfSUKL7idTqkfyI-sslh0f43ZYcRpK2M0=.34bd1893-3b67-4d08-bbaf-389022f89923@github.com>

On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - Step 2: Update references
>  - First stage, move actual data files

Marked as reviewed by erikj (Reviewer).

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

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

From prr at openjdk.java.net  Mon Jan  4 20:34:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 4 Jan 2021 20:34:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v2]
In-Reply-To: <7qjMCFOBix6UV1-FNgDfcBNkKvMXApGdA-f-9LvojRo=.c8334604-98f2-4baa-8a0b-abb171b6e1cf@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <7qjMCFOBix6UV1-FNgDfcBNkKvMXApGdA-f-9LvojRo=.c8334604-98f2-4baa-8a0b-abb171b6e1cf@github.com>
Message-ID: <an-c1G_LPDYq7uENLOsQfvBVmToQwwwRoVbdqNpxEHY=.34f5bdaa-75e9-4e49-a933-a53b75438cee@github.com>

On Mon, 4 Jan 2021 10:27:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fail the test if no printer is found

test/jdk/java/awt/print/PrinterJob/LandscapeStackOverflow.java line 50:

> 48:         PrintService defaultPrtSrv = PrintServiceLookup.lookupDefaultPrintService();
> 49:         if (printjob.getPrintService() == null || defaultPrtSrv == null) {
> 50:             throw new RuntimeException("No printer found");

We need to make this more robust.
The checks should be before we create the pritner job and should be to find ANY printer and none
throws the excepton, but if there is only a non-default one, set that as the printer for the job after creating the job.

That may not matter on Windows but on other platforms I am sure you can have printers, but not a default one.

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

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

From prr at openjdk.java.net  Mon Jan  4 21:09:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 4 Jan 2021 21:09:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259042: Inconsistent use of general
 primitives loops
In-Reply-To: <Z0dnXH-TKnljzd11XC15CeXXyjOjLJpwdPIjP7cmH3g=.bbd2a121-f7b7-4913-8746-26c8cdbb01b8@github.com>
References: <Z0dnXH-TKnljzd11XC15CeXXyjOjLJpwdPIjP7cmH3g=.bbd2a121-f7b7-4913-8746-26c8cdbb01b8@github.com>
Message-ID: <4JxEORig0xHMcgC9lsU7h62f3hWNA5bCg_7ZM8mLBNs=.53a8e713-b413-49da-88a9-0b88bad6a2c5@github.com>

On Mon, 4 Jan 2021 08:09:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The java2d uses the primitives such as Blit loop for rendering differing things. Currently, not all possible variants of primitives are implemented, but it is possible to register some general loop that may produce the primitives for some specific src/comp/dst.
> 
> But we have some inconsistent here:
>  - Some primitives register themselves as a general loop but always return null in the makePrimitive() method
>  - Some primitives (which are not registered as general loops) return null or throw an error in the makePrimitive() method
> 
> After the fix:
>  - The primitive will be registered as a general primitive only if it has a meaningful makePrimitive method
>  - An attempt to call the makePrimitive for non registered general loop will cause an error
> 
> mach5 is green

Marked as reviewed by prr (Reviewer).

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

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

From prr at openjdk.java.net  Mon Jan  4 21:11:58 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 4 Jan 2021 21:11:58 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8257809: JNI warnings from Toolkit
 JPEG image decoding
In-Reply-To: <fSJstPuGwn4PqeN9JTO4YSpvC7WG9iPQYyPmMivV-YA=.979b8669-0299-4ca7-8f91-af9fa764384a@github.com>
References: <fSJstPuGwn4PqeN9JTO4YSpvC7WG9iPQYyPmMivV-YA=.979b8669-0299-4ca7-8f91-af9fa764384a@github.com>
Message-ID: <XkFIwrYoHNIGWSjdkKZomOXbPNZGwlRXont-wSz9T6M=.dca67a5e-b3cc-4a08-899d-d75f693ed91c@github.com>

On Sun, 20 Dec 2020 01:37:47 GMT, Phil Race <prr at openjdk.org> wrote:

> The fix is to reverse the order of acquisition to get dst before src so that the call to GetArrayLength() comes first.
> This also necessitates moving the RELEASE_ARRAYS() call on an error condition to the new "2nd" block.
> 
> The new regression test passes on all platforms and all the other headless tests passed too.
> So do the automated headful tests.

This pull request has now been integrated.

Changeset: e6f99260
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e6f99260
Stats:     126 lines in 4 files changed: 116 ins; 10 del; 0 mod

8257809: JNI warnings from Toolkit JPEG image decoding

Reviewed-by: serb

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

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

From prr at openjdk.java.net  Mon Jan  4 21:24:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 4 Jan 2021 21:24:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module [v4]
In-Reply-To: <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
Message-ID: <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>

On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - Step 2: Update references
>  - First stage, move actual data files

Marked as reviewed by prr (Reviewer).

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

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

From prr at openjdk.java.net  Mon Jan  4 21:25:59 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 4 Jan 2021 21:25:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8256321: Some "inactive" color profiles
 use the wrong profile class
In-Reply-To: <t4N47mFPG8OIFfpgHr4nsD6gPuoXX_xyJdoId4P_hss=.f0293d97-6535-4821-86df-8f07cf3b27bb@github.com>
References: <t4N47mFPG8OIFfpgHr4nsD6gPuoXX_xyJdoId4P_hss=.f0293d97-6535-4821-86df-8f07cf3b27bb@github.com>
Message-ID: <OlLkBbkEjODu_VKcp9xKY8S0SbEr-PETwLXgbeA7gdQ=.7c2d3642-6b65-4cf0-9e9d-fb0b194ed858@github.com>

On Fri, 13 Nov 2020 22:50:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The implementation of ICC_Profile tries to defer loading the data of the color profile, and it uses some predefined values for some profile properties for the standard profiles like sRGB, PYCC, etc. If the application requests profile data then the ICC_Profile class activates the profile and uses properties from that data.
> 
> Deferring mechanism for all profiles was added in JDK-6793818, but unfortunately, the color profile class was hardcoded incorrectly "CLASS_DISPLAY" for all profiles. However, the "CIEXYZ.pf" and "PYCC.pf" profiles should use "CLASS_COLORSPACECONVERSION".
> 
> Later the color "profiles/xxx.pf" were replaced in the JDK, and the actual type of the "CIEXYZ.pf" was changed to the "CLASS_ABSTRACT", but the deferring mechanism still uses "CLASS_DISPLAY".
> 
> As a result of this bug, the color profile reports different values before/after activations.

Marked as reviewed by prr (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Tue Jan  5 08:33:06 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 5 Jan 2021 08:33:06 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259007: This test printed a blank
 page
Message-ID: <ehFo23olzN-WhfU6TnpBKIHE1vaZD6UH5MbPG55PXbs=.032abc81-7947-493a-bae3-a81f87edceb2@github.com>

Backout JDK-8256264 fix.

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

Commit messages:
 - 8259007: This test printed a blank page

Changes: https://git.openjdk.java.net/jdk16/pull/80/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=80&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259007
  Stats: 470 lines in 4 files changed: 0 ins; 459 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/80.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/80/head:pull/80

PR: https://git.openjdk.java.net/jdk16/pull/80

From psadhukhan at openjdk.java.net  Tue Jan  5 09:08:15 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 5 Jan 2021 09:08:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v3]
In-Reply-To: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
Message-ID: <seXrgOTP8zt2mw3gwC54v-VuWlOPGZYCaQa6fUMD3Lo=.1b04ffd2-453e-40f2-9dfb-406325d9320d@github.com>

> Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - jckech issue fix
 - Make printer search more robust

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1927/files
  - new: https://git.openjdk.java.net/jdk/pull/1927/files/d4d70e34..7098cb41

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

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

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

From serb at openjdk.java.net  Tue Jan  5 12:52:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 5 Jan 2021 12:52:58 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8256321: Some "inactive" color
 profiles use the wrong profile class
In-Reply-To: <t4N47mFPG8OIFfpgHr4nsD6gPuoXX_xyJdoId4P_hss=.f0293d97-6535-4821-86df-8f07cf3b27bb@github.com>
References: <t4N47mFPG8OIFfpgHr4nsD6gPuoXX_xyJdoId4P_hss=.f0293d97-6535-4821-86df-8f07cf3b27bb@github.com>
Message-ID: <r8HsqZ1T66zgMFtrxglKprb8Fj_6POpa4_k0VrQdDSI=.c2ecdf24-6476-4409-9c7d-cad8532aee51@github.com>

On Fri, 13 Nov 2020 22:50:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The implementation of ICC_Profile tries to defer loading the data of the color profile, and it uses some predefined values for some profile properties for the standard profiles like sRGB, PYCC, etc. If the application requests profile data then the ICC_Profile class activates the profile and uses properties from that data.
> 
> Deferring mechanism for all profiles was added in JDK-6793818, but unfortunately, the color profile class was hardcoded incorrectly "CLASS_DISPLAY" for all profiles. However, the "CIEXYZ.pf" and "PYCC.pf" profiles should use "CLASS_COLORSPACECONVERSION".
> 
> Later the color "profiles/xxx.pf" were replaced in the JDK, and the actual type of the "CIEXYZ.pf" was changed to the "CLASS_ABSTRACT", but the deferring mechanism still uses "CLASS_DISPLAY".
> 
> As a result of this bug, the color profile reports different values before/after activations.

This pull request has now been integrated.

Changeset: a6c08813
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6c08813
Stats:     87 lines in 2 files changed: 85 ins; 0 del; 2 mod

8256321: Some "inactive" color profiles use the wrong profile class

Reviewed-by: prr

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

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

From prr at openjdk.java.net  Tue Jan  5 16:31:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 5 Jan 2021 16:31:57 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259007: This test printed a
 blank page
In-Reply-To: <ehFo23olzN-WhfU6TnpBKIHE1vaZD6UH5MbPG55PXbs=.032abc81-7947-493a-bae3-a81f87edceb2@github.com>
References: <ehFo23olzN-WhfU6TnpBKIHE1vaZD6UH5MbPG55PXbs=.032abc81-7947-493a-bae3-a81f87edceb2@github.com>
Message-ID: <ICJsTkg8at7wbl4IfXoiNXbYQatYzy1_Zg8I1wSBfVI=.183c07f9-c95c-4456-b4e7-5f17155b1020@github.com>

On Tue, 5 Jan 2021 08:28:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Backout JDK-8256264 fix.

I assume you tested this does indeed fix the regressipn ?
Approving on that understanding.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/80

From prr at openjdk.java.net  Tue Jan  5 16:36:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 5 Jan 2021 16:36:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v2]
In-Reply-To: <an-c1G_LPDYq7uENLOsQfvBVmToQwwwRoVbdqNpxEHY=.34f5bdaa-75e9-4e49-a933-a53b75438cee@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <7qjMCFOBix6UV1-FNgDfcBNkKvMXApGdA-f-9LvojRo=.c8334604-98f2-4baa-8a0b-abb171b6e1cf@github.com>
 <an-c1G_LPDYq7uENLOsQfvBVmToQwwwRoVbdqNpxEHY=.34f5bdaa-75e9-4e49-a933-a53b75438cee@github.com>
Message-ID: <4O58ozI6UL_quW_Oaf3TgkMOiMYNoBzXaDbGVQHbJW8=.a9e26885-55b7-4247-ad2d-325263d7044a@github.com>

On Mon, 4 Jan 2021 20:31:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fail the test if no printer is found
>
> test/jdk/java/awt/print/PrinterJob/LandscapeStackOverflow.java line 50:
> 
>> 48:         PrintService defaultPrtSrv = PrintServiceLookup.lookupDefaultPrintService();
>> 49:         if (printjob.getPrintService() == null || defaultPrtSrv == null) {
>> 50:             throw new RuntimeException("No printer found");
> 
> We need to make this more robust.
> The checks should be before we create the pritner job and should be to find ANY printer and none
> throws the excepton, but if there is only a non-default one, set that as the printer for the job after creating the job.
> 
> That may not matter on Windows but on other platforms I am sure you can have printers, but not a default one.

>         if (printService.length == 1) {

So if there are two, you do nothing ?

I was thinking of code like this

PrintService[] printService = PrinterJob.lookupPrintServices();
if (printService.length == 0) {
   throw new RuntimeException("no printer found");
}
PrinterJob printjob = PrinterJob.getPrinterJob();
if  (printjob.getPrintService() == null) {
    printjob.setPrintService(printService[0]);
}

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

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

From serb at openjdk.java.net  Tue Jan  5 23:36:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 5 Jan 2021 23:36:57 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259007: This test printed a
 blank page
In-Reply-To: <ehFo23olzN-WhfU6TnpBKIHE1vaZD6UH5MbPG55PXbs=.032abc81-7947-493a-bae3-a81f87edceb2@github.com>
References: <ehFo23olzN-WhfU6TnpBKIHE1vaZD6UH5MbPG55PXbs=.032abc81-7947-493a-bae3-a81f87edceb2@github.com>
Message-ID: <5IeE9I8sVWZ-UCgiS0IehFWbU3vKWkhl5TDl_1nTJGE=.feaecc78-2846-4229-a916-c420d496e546@github.com>

On Tue, 5 Jan 2021 08:28:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Backout JDK-8256264 fix.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/80

From serb at openjdk.java.net  Wed Jan  6 00:04:55 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Jan 2021 00:04:55 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259007: This test printed a
 blank page
In-Reply-To: <5IeE9I8sVWZ-UCgiS0IehFWbU3vKWkhl5TDl_1nTJGE=.feaecc78-2846-4229-a916-c420d496e546@github.com>
References: <ehFo23olzN-WhfU6TnpBKIHE1vaZD6UH5MbPG55PXbs=.032abc81-7947-493a-bae3-a81f87edceb2@github.com>
 <5IeE9I8sVWZ-UCgiS0IehFWbU3vKWkhl5TDl_1nTJGE=.feaecc78-2846-4229-a916-c420d496e546@github.com>
Message-ID: <Cnf2XrrMzV6-F6waf_P38x-tfqxNzslinHz9gdAgIuk=.a4886764-992a-47b7-8a0e-158eff851c7e@github.com>

On Tue, 5 Jan 2021 23:34:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Backout JDK-8256264 fix.
>
> Marked as reviewed by serb (Reviewer).

The fix for JDK-8256264 made an assumption that moveTo/lineTo methods are always wrapped by the beginPath/endPath. So that fix sets the scale in the beginPath/endPath and correct the passed parameters in the moveTo/lineTo. But this new code in the moveTo/lineTo does not work well if the beginPath was not called.

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

PR: https://git.openjdk.java.net/jdk16/pull/80

From psadhukhan at openjdk.java.net  Wed Jan  6 04:29:11 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 04:29:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v2]
In-Reply-To: <4O58ozI6UL_quW_Oaf3TgkMOiMYNoBzXaDbGVQHbJW8=.a9e26885-55b7-4247-ad2d-325263d7044a@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <7qjMCFOBix6UV1-FNgDfcBNkKvMXApGdA-f-9LvojRo=.c8334604-98f2-4baa-8a0b-abb171b6e1cf@github.com>
 <an-c1G_LPDYq7uENLOsQfvBVmToQwwwRoVbdqNpxEHY=.34f5bdaa-75e9-4e49-a933-a53b75438cee@github.com>
 <4O58ozI6UL_quW_Oaf3TgkMOiMYNoBzXaDbGVQHbJW8=.a9e26885-55b7-4247-ad2d-325263d7044a@github.com>
Message-ID: <KDPUvM0trJaeea87EGcZX8toLwU38td0ttUhYSnBQrk=.30221a1b-51c6-449b-8d14-56e39113c26a@github.com>

On Tue, 5 Jan 2021 16:34:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/LandscapeStackOverflow.java line 50:
>> 
>>> 48:         PrintService defaultPrtSrv = PrintServiceLookup.lookupDefaultPrintService();
>>> 49:         if (printjob.getPrintService() == null || defaultPrtSrv == null) {
>>> 50:             throw new RuntimeException("No printer found");
>> 
>> We need to make this more robust.
>> The checks should be before we create the pritner job and should be to find ANY printer and none
>> throws the excepton, but if there is only a non-default one, set that as the printer for the job after creating the job.
>> 
>> That may not matter on Windows but on other platforms I am sure you can have printers, but not a default one.
>
>>         if (printService.length == 1) {
> 
> So if there are two, you do nothing ?
> 
> I was thinking of code like this
> 
> PrintService[] printService = PrinterJob.lookupPrintServices();
> if (printService.length == 0) {
>    throw new RuntimeException("no printer found");
> }
> PrinterJob printjob = PrinterJob.getPrinterJob();
> if  (printjob.getPrintService() == null) {
>     printjob.setPrintService(printService[0]);
> }

I was of the understanding that if there are multiple, then we have to choose one as default so defaultPrintService will not be null. But, the above code looks more apt.

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

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

From psadhukhan at openjdk.java.net  Wed Jan  6 04:29:10 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 04:29:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v4]
In-Reply-To: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
Message-ID: <gvFaoh-yNLuk_A48xGgSkRAsxgI0mGlWgdDuW1dmTfw=.a2960e99-ce71-4ee7-98d3-c62d6f2118ec@github.com>

> Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1927/files
  - new: https://git.openjdk.java.net/jdk/pull/1927/files/7098cb41..8ed618f2

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

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

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

From psadhukhan at openjdk.java.net  Wed Jan  6 04:37:03 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 04:37:03 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259007: This test printed a
 blank page
In-Reply-To: <ICJsTkg8at7wbl4IfXoiNXbYQatYzy1_Zg8I1wSBfVI=.183c07f9-c95c-4456-b4e7-5f17155b1020@github.com>
References: <ehFo23olzN-WhfU6TnpBKIHE1vaZD6UH5MbPG55PXbs=.032abc81-7947-493a-bae3-a81f87edceb2@github.com>
 <ICJsTkg8at7wbl4IfXoiNXbYQatYzy1_Zg8I1wSBfVI=.183c07f9-c95c-4456-b4e7-5f17155b1020@github.com>
Message-ID: <Tq3xz8voao09bz2ncR2gXrM0PkTMmG8y4Odnw2Udz38=.c33a9ef3-babc-4c6c-b532-e0c1f69d64ce@github.com>

On Tue, 5 Jan 2021 16:29:23 GMT, Phil Race <prr at openjdk.org> wrote:

> 
> 
> I assume you tested this does indeed fix the regressipn ?
> Approving on that understanding.

Yes, it does fix in my testing and I also got confirmation from EG that this patch fix the issues.

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

PR: https://git.openjdk.java.net/jdk16/pull/80

From serb at openjdk.java.net  Wed Jan  6 04:58:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Jan 2021 04:58:01 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v4]
In-Reply-To: <gvFaoh-yNLuk_A48xGgSkRAsxgI0mGlWgdDuW1dmTfw=.a2960e99-ce71-4ee7-98d3-c62d6f2118ec@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <gvFaoh-yNLuk_A48xGgSkRAsxgI0mGlWgdDuW1dmTfw=.a2960e99-ce71-4ee7-98d3-c62d6f2118ec@github.com>
Message-ID: <LeCyalNDOk9o1c76qpJHbWX4tAShXcdx8e97Gzlt8VI=.c581bfe2-4434-42aa-9d47-a6b73de1c82d@github.com>

On Wed, 6 Jan 2021 04:29:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix code

test/jdk/java/awt/print/PrinterJob/LandscapeStackOverflow.java line 46:

> 44: 
> 45:     public static final void main( String[] parameters ) throws Exception {
> 46:         PrintService[] printService = PrinterJob.lookupPrintServices();

As far as I understand and comment in my previouse comment, if the lookupPrintServices() return empty array then the "PrinterJob.print()" will throw the same PrinterException("No print service found");

And if default printer is not set, and we have some other printers then "PrinterJob.print()" will select some non-default printer already, isn't it?

I meant that we just duplicate an existed checks, and both of them wll not work. If the system has some non-real printers like XPS, or "print to PDF" then such printers will be count  by the "PrinterJob.lookupPrintServices()" so no exception will be thrown and the test just hands suggestion the user to save the printed document somewhere. The hang occur exactly where it is reported in JBS "WPrinterJob._startDoc".

I can reproduce it on the freshly installed Windows.

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

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

From psadhukhan at openjdk.java.net  Wed Jan  6 06:37:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 06:37:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v4]
In-Reply-To: <LeCyalNDOk9o1c76qpJHbWX4tAShXcdx8e97Gzlt8VI=.c581bfe2-4434-42aa-9d47-a6b73de1c82d@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <gvFaoh-yNLuk_A48xGgSkRAsxgI0mGlWgdDuW1dmTfw=.a2960e99-ce71-4ee7-98d3-c62d6f2118ec@github.com>
 <LeCyalNDOk9o1c76qpJHbWX4tAShXcdx8e97Gzlt8VI=.c581bfe2-4434-42aa-9d47-a6b73de1c82d@github.com>
Message-ID: <Y4PrzQzb7ms6nAi0aX2-h-JIchbZk1j9O9EAZcd1LPM=.15ee6e17-02ad-4412-a883-905c6f311e50@github.com>

On Wed, 6 Jan 2021 04:55:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix code
>
> test/jdk/java/awt/print/PrinterJob/LandscapeStackOverflow.java line 46:
> 
>> 44: 
>> 45:     public static final void main( String[] parameters ) throws Exception {
>> 46:         PrintService[] printService = PrinterJob.lookupPrintServices();
> 
> As far as I understand and comment in my previouse comment, if the lookupPrintServices() return empty array then the "PrinterJob.print()" will throw the same PrinterException("No print service found");
> 
> And if default printer is not set, and we have some other printers then "PrinterJob.print()" will select some non-default printer already, isn't it?
> 
> I meant that we just duplicate an existed checks, and both of them wll not work. If the system has some non-real printers like XPS, or "print to PDF" then such printers will be count  by the "PrinterJob.lookupPrintServices()" so no exception will be thrown and the test just hands suggestion the user to save the printed document somewhere. The hang occur exactly where it is reported in JBS "WPrinterJob._startDoc".
> 
> I can reproduce it on the freshly installed Windows.

I'm not sure we can avoid this if user selects "print to pdf" as default printservice or if it is the only printservice available. Maybe converting it to manual is the way to go.

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

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

From psadhukhan at openjdk.java.net  Wed Jan  6 06:39:59 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 06:39:59 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] Integrated: 8259007: This test printed a
 blank page
In-Reply-To: <ehFo23olzN-WhfU6TnpBKIHE1vaZD6UH5MbPG55PXbs=.032abc81-7947-493a-bae3-a81f87edceb2@github.com>
References: <ehFo23olzN-WhfU6TnpBKIHE1vaZD6UH5MbPG55PXbs=.032abc81-7947-493a-bae3-a81f87edceb2@github.com>
Message-ID: <592pk01b29mAgL-EDR7ndCQqKF6ysK32PSjt5zydSPY=.6fa34f64-5f5d-4a8e-ba81-c7c4239b0b49@github.com>

On Tue, 5 Jan 2021 08:28:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Backout JDK-8256264 fix.

This pull request has now been integrated.

Changeset: 80110dac
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/80110dac
Stats:     470 lines in 4 files changed: 0 ins; 459 del; 11 mod

8259007: This test printed a blank page

Reviewed-by: prr, serb

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

PR: https://git.openjdk.java.net/jdk16/pull/80

From serb at openjdk.java.net  Wed Jan  6 06:45:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Jan 2021 06:45:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v4]
In-Reply-To: <Y4PrzQzb7ms6nAi0aX2-h-JIchbZk1j9O9EAZcd1LPM=.15ee6e17-02ad-4412-a883-905c6f311e50@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <gvFaoh-yNLuk_A48xGgSkRAsxgI0mGlWgdDuW1dmTfw=.a2960e99-ce71-4ee7-98d3-c62d6f2118ec@github.com>
 <LeCyalNDOk9o1c76qpJHbWX4tAShXcdx8e97Gzlt8VI=.c581bfe2-4434-42aa-9d47-a6b73de1c82d@github.com>
 <Y4PrzQzb7ms6nAi0aX2-h-JIchbZk1j9O9EAZcd1LPM=.15ee6e17-02ad-4412-a883-905c6f311e50@github.com>
Message-ID: <WSWP4l9Qwf2uZjhAQtvCLZQnrnmmn5MSkwNO5ioTtX8=.e9a40832-e181-438a-b20a-fa9395b063ab@github.com>

On Wed, 6 Jan 2021 06:35:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/LandscapeStackOverflow.java line 46:
>> 
>>> 44: 
>>> 45:     public static final void main( String[] parameters ) throws Exception {
>>> 46:         PrintService[] printService = PrinterJob.lookupPrintServices();
>> 
>> As far as I understand and comment in my previouse comment, if the lookupPrintServices() return empty array then the "PrinterJob.print()" will throw the same PrinterException("No print service found");
>> 
>> And if default printer is not set, and we have some other printers then "PrinterJob.print()" will select some non-default printer already, isn't it?
>> 
>> I meant that we just duplicate an existed checks, and both of them wll not work. If the system has some non-real printers like XPS, or "print to PDF" then such printers will be count  by the "PrinterJob.lookupPrintServices()" so no exception will be thrown and the test just hands suggestion the user to save the printed document somewhere. The hang occur exactly where it is reported in JBS "WPrinterJob._startDoc".
>> 
>> I can reproduce it on the freshly installed Windows.
>
> I'm not sure we can avoid this if user selects "print to pdf" as default printservice or if it is the only printservice available. Maybe converting it to manual is the way to go.

We can update the documentation "testing.html" about the "printer" keyword and describe how to skip/run the tests marked by this keyword. or we can just close the bug as not-a-defect.

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

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

From psadhukhan at openjdk.java.net  Wed Jan  6 07:02:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 6 Jan 2021 07:02:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259232: Bad JNI lookup during printing
In-Reply-To: <h-UyGAWVphh1bYoHpKwq38xu8M7wzfKYr_QkrxWF-f0=.11092a1a-2f54-42d3-9ef7-054a6b134572@github.com>
References: <h-UyGAWVphh1bYoHpKwq38xu8M7wzfKYr_QkrxWF-f0=.11092a1a-2f54-42d3-9ef7-054a6b134572@github.com>
Message-ID: <XoRrXFj862u4tK86KgxisoVmOCqwrQGy2JBT0s_1j20=.2d1de26e-feed-42dc-b5c0-488fa957af98@github.com>

On Wed, 6 Jan 2021 01:17:02 GMT, Phil Race <prr at openjdk.org> wrote:

> Didn't hit this because all the print testing I conducted used the swing print + page dialog but the logging made it easy to find the source of the problem.
> I've also done an audit of GET_METHOD_* usages for this pattern - I had previously done it for DECLARE_METHOD* which is the bulk.

Marked as reviewed by psadhukhan (Reviewer).

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

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

From serb at openjdk.java.net  Wed Jan  6 10:09:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Jan 2021 10:09:56 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8259042: Inconsistent use of general
 primitives loops
In-Reply-To: <Z0dnXH-TKnljzd11XC15CeXXyjOjLJpwdPIjP7cmH3g=.bbd2a121-f7b7-4913-8746-26c8cdbb01b8@github.com>
References: <Z0dnXH-TKnljzd11XC15CeXXyjOjLJpwdPIjP7cmH3g=.bbd2a121-f7b7-4913-8746-26c8cdbb01b8@github.com>
Message-ID: <0Opv1nzW_s0kfaXnLwwNxbcSWY_vEgtsjoguhOjVQ8U=.c3cee7e8-fa49-41f2-be52-2a416fde3049@github.com>

On Mon, 4 Jan 2021 08:09:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The java2d uses the primitives such as Blit loop for rendering differing things. Currently, not all possible variants of primitives are implemented, but it is possible to register some general loop that may produce the primitives for some specific src/comp/dst.
> 
> But we have some inconsistent here:
>  - Some primitives register themselves as a general loop but always return null in the makePrimitive() method
>  - Some primitives (which are not registered as general loops) return null or throw an error in the makePrimitive() method
> 
> After the fix:
>  - The primitive will be registered as a general primitive only if it has a meaningful makePrimitive method
>  - An attempt to call the makePrimitive for non registered general loop will cause an error
> 
> mach5 is green

This pull request has now been integrated.

Changeset: 8a05d605
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8a05d605
Stats:     260 lines in 22 files changed: 33 ins; 167 del; 60 mod

8259042: Inconsistent use of general primitives loops

Reviewed-by: prr

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

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

From prr at openjdk.java.net  Wed Jan  6 17:36:55 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 6 Jan 2021 17:36:55 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8259232: Bad JNI lookup during printing
In-Reply-To: <h-UyGAWVphh1bYoHpKwq38xu8M7wzfKYr_QkrxWF-f0=.11092a1a-2f54-42d3-9ef7-054a6b134572@github.com>
References: <h-UyGAWVphh1bYoHpKwq38xu8M7wzfKYr_QkrxWF-f0=.11092a1a-2f54-42d3-9ef7-054a6b134572@github.com>
Message-ID: <l2igBko5qgWS6AWP4RaCGEBK5qxmdwQA0CGzE2kuZ1s=.90c9553e-a2b0-43ef-b1bb-c7838243e5b6@github.com>

On Wed, 6 Jan 2021 01:17:02 GMT, Phil Race <prr at openjdk.org> wrote:

> Didn't hit this because all the print testing I conducted used the swing print + page dialog but the logging made it easy to find the source of the problem.
> I've also done an audit of GET_METHOD_* usages for this pattern - I had previously done it for DECLARE_METHOD* which is the bulk.

This pull request has now been integrated.

Changeset: 940b0530
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/940b0530
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8259232: Bad JNI lookup during printing

Reviewed-by: psadhukhan

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

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

From serb at openjdk.java.net  Wed Jan  6 19:39:02 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Jan 2021 19:39:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259232: Bad JNI lookup during printing
In-Reply-To: <h-UyGAWVphh1bYoHpKwq38xu8M7wzfKYr_QkrxWF-f0=.11092a1a-2f54-42d3-9ef7-054a6b134572@github.com>
References: <h-UyGAWVphh1bYoHpKwq38xu8M7wzfKYr_QkrxWF-f0=.11092a1a-2f54-42d3-9ef7-054a6b134572@github.com>
Message-ID: <i_C6X33i-CUU-qaLDrH3WJGRAns8IKh0g6nJkzXIpYQ=.7ccff926-d58c-4643-a1e9-adf8c485b2b9@github.com>

On Wed, 6 Jan 2021 01:17:02 GMT, Phil Race <prr at openjdk.org> wrote:

> Didn't hit this because all the print testing I conducted used the swing print + page dialog but the logging made it easy to find the source of the problem.
> I've also done an audit of GET_METHOD_* usages for this pattern - I had previously done it for DECLARE_METHOD* which is the bulk.

src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 59:

> 57:     GET_METHOD_RETURN(sjm_getNSPrintInfo, sjc_CPrinterJob, "getNSPrintInfo", "()J", ret);
> 58: 
> 59: #define GET_CPRINTERDIALOG_METHOD_RETURN(ret) \

I guess the name of the macro should be renamed as well?

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

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

From serb at openjdk.java.net  Thu Jan  7 02:09:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Jan 2021 02:09:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException [v2]
In-Reply-To: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
Message-ID: <-e0tgOvR6d52wrXo-w_8I-T3phJxifYXIYmicD2BBaQ=.d0550cdd-adcc-4ae6-9bb5-4f27067f4205@github.com>

> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
> 
> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
> 
> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
> 
> Notes about the link above:
> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
> 
> The fix:
>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
> 
> See some comments inline.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Delete the DeferralMgr machinery
 - Update ICC_Profile.java
 - Wrong spec in ProfileDeferralInfo
 - Update ICC_Profile.java
 - Race on access ICC_Profile#deferralInfo
 - Implementation of thread-safe per profile activation
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/67c22114...a5b2af2f

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

Changes: https://git.openjdk.java.net/jdk/pull/1613/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1613&range=01
  Stats: 520 lines in 9 files changed: 183 ins; 265 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1613/head:pull/1613

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

From serb at openjdk.java.net  Thu Jan  7 02:25:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Jan 2021 02:25:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException [v3]
In-Reply-To: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
Message-ID: <Ms0UQmIY8od4M3jwTyj58G99jR09Qi_SwststKhfVmE=.cab307b4-b555-4161-bd23-9577bb30cac9@github.com>

> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
> 
> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
> 
> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
> 
> Notes about the link above:
> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
> 
> The fix:
>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
> 
> See some comments inline.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Update ProfileActivationDuringPropertyAccess.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1613/files
  - new: https://git.openjdk.java.net/jdk/pull/1613/files/a5b2af2f..fb32b3f4

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

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

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

From mbaesken at openjdk.java.net  Thu Jan  7 08:57:04 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 7 Jan 2021 08:57:04 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8258484: AIX build fails in Harfbuzz with
 XLC 16.01.0000.0006
Message-ID: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com>

Hello,  for a while the AIX build fails with the following error in the harfbuzz build 
    1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const.
Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined.

This xlc 16 version is used for compiling 
bash-4.4$ xlc -qversion
IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12)
Version: 16.01.0000.0006

Solution by IBM compiler support is to use  "-qdebug=necan", this  effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib.

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

Commit messages:
 - JDK-8258484

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

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

From mbaesken at openjdk.java.net  Thu Jan  7 09:34:09 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 7 Jan 2021 09:34:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8258484: AIX build fails in Harfbuzz
 with XLC 16.01.0000.0006 [v2]
In-Reply-To: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com>
References: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com>
Message-ID: <GPbSFMUUnIvxlD7eRhKhMkPeCyk_XKIAy1WSJ0QQN0A=.fe496c31-0b0d-416e-baeb-7958015032ac@github.com>

> Hello,  for a while the AIX build fails with the following error in the harfbuzz build 
>     1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const.
> Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined.
> 
> This xlc 16 version is used for compiling 
> bash-4.4$ xlc -qversion
> IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12)
> Version: 16.01.0000.0006
> 
> Solution by IBM compiler support is to use  "-qdebug=necan", this  effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib.

Matthias Baesken has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - Adjust comment
 - JDK-8258484

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1972/files
  - new: https://git.openjdk.java.net/jdk/pull/1972/files/ecd93d06..27205b26

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

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

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

From clanger at openjdk.java.net  Thu Jan  7 09:34:10 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Thu, 7 Jan 2021 09:34:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8258484: AIX build fails in Harfbuzz
 with XLC 16.01.0000.0006 [v2]
In-Reply-To: <GPbSFMUUnIvxlD7eRhKhMkPeCyk_XKIAy1WSJ0QQN0A=.fe496c31-0b0d-416e-baeb-7958015032ac@github.com>
References: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com>
 <GPbSFMUUnIvxlD7eRhKhMkPeCyk_XKIAy1WSJ0QQN0A=.fe496c31-0b0d-416e-baeb-7958015032ac@github.com>
Message-ID: <btl78G_3DlZGwMdHMRXXBWWbaezA218CZXqhAbE7Ios=.86d22f9e-5a5b-4859-937b-36f138a11baf@github.com>

On Thu, 7 Jan 2021 09:19:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello,  for a while the AIX build fails with the following error in the harfbuzz build 
>>     1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const.
>> Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined.
>> 
>> This xlc 16 version is used for compiling 
>> bash-4.4$ xlc -qversion
>> IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12)
>> Version: 16.01.0000.0006
>> 
>> Solution by IBM compiler support is to use  "-qdebug=necan", this  effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib.
>
> Matthias Baesken has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Adjust comment
>  - JDK-8258484

Hi Matthias,

looks good to me in principal. I would spell out the abbreviation ICE, though, otherwise somebody reading this later could have difficulties to grok it ;-)

Thanks
Christoph

Maybe better:
Early re-canonizing has to be disabled to workaround an internal XlC compiler error when building libharfbuzz
?

LGTM now :)

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

Changes requested by clanger (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1972Marked as reviewed by clanger (Reviewer).

From mdoerr at openjdk.java.net  Thu Jan  7 10:14:59 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 7 Jan 2021 10:14:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8258484: AIX build fails in Harfbuzz
 with XLC 16.01.0000.0006 [v2]
In-Reply-To: <GPbSFMUUnIvxlD7eRhKhMkPeCyk_XKIAy1WSJ0QQN0A=.fe496c31-0b0d-416e-baeb-7958015032ac@github.com>
References: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com>
 <GPbSFMUUnIvxlD7eRhKhMkPeCyk_XKIAy1WSJ0QQN0A=.fe496c31-0b0d-416e-baeb-7958015032ac@github.com>
Message-ID: <vLFLDKsX08NHU-11I3965hzUtU-7TH48ppa7XoHK5i0=.6a919814-407d-47d2-bf47-137035447aa5@github.com>

On Thu, 7 Jan 2021 09:34:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello,  for a while the AIX build fails with the following error in the harfbuzz build 
>>     1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const.
>> Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined.
>> 
>> This xlc 16 version is used for compiling 
>> bash-4.4$ xlc -qversion
>> IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12)
>> Version: 16.01.0000.0006
>> 
>> Solution by IBM compiler support is to use  "-qdebug=necan", this  effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib.
>
> Matthias Baesken has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by mdoerr (Reviewer).

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

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

From mbaesken at openjdk.java.net  Thu Jan  7 12:43:00 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 7 Jan 2021 12:43:00 GMT
Subject: [OpenJDK 2D-Dev] Integrated: JDK-8258484: AIX build fails in
 Harfbuzz with XLC 16.01.0000.0006
In-Reply-To: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com>
References: <2c1_uxFtoGC0thMIRFzfazpmpMDN90qO7oA2w5vYUsk=.485c854f-1f0c-4718-ba12-35a0cd77c041@github.com>
Message-ID: <l7ULSoRClbSPlRP9cfIsF-njy2dSqEulsH8RGsw4fJc=.4b8d097f-d121-4993-8ab7-fc19458375b2@github.com>

On Thu, 7 Jan 2021 08:51:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello,  for a while the AIX build fails with the following error in the harfbuzz build 
>     1500-004: (U) INTERNAL COMPILER ERROR while compiling OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_context_t *) const.
> Compilation ended. Contact your Service Representative and provide the following information: GRARNN: gr29643 is used before it is defined.
> 
> This xlc 16 version is used for compiling 
> bash-4.4$ xlc -qversion
> IBM XL C/C++ for AIX, V16.1.0 (5725-C72, 5765-J12)
> Version: 16.01.0000.0006
> 
> Solution by IBM compiler support is to use  "-qdebug=necan", this  effectively turns off an optimisation called "Early Re-canonizing" on the harfbuzz lib.

This pull request has now been integrated.

Changeset: 3f9f86f0
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3f9f86f0
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006

Reviewed-by: clanger, mdoerr

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

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

From sgehwolf at redhat.com  Thu Jan  7 17:31:57 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 07 Jan 2021 18:31:57 +0100
Subject: [OpenJDK 2D-Dev] [11u] Backport of 8247872: Upgrade HarfBuzz to
 the latest 2.7.2
In-Reply-To: <AM4PR02MB3057E76ABABD7ED56E2F7CFF9AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB3057E76ABABD7ED56E2F7CFF9AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <32e197f5ec5fce10f1aaf06260c54b0328c7549b.camel@redhat.com>

On Thu, 2021-01-07 at 17:16 +0000, Doerr, Martin wrote:
> Hi,
> 
> I've created a jdk11u backport of JDK-8247872: Upgrade HarfBuzz to
> the latest 2.7.2
> http://cr.openjdk.java.net/~mdoerr/8247872_harfbuzz_11u/webrev.00/
> 
> I had to resolve it a bit manually [1].
> However, the main problem is that it heavily uses C++11, so easiest
> solution is to add HARFBUZZ_CFLAGS := -std=c++11.
> This works for all supported compilers [2] except xlC on AIX and sun
> studio on Solaris.

We are building vanilla JDK 11 builds with gcc 4.4.7 which doesn't
support the -std=c++11 option. We've had issues in that area before.
See JDK-8256557.

Thanks,
Severin

> I could envision different solutions:
> 
> ? 1.? Change code to work with older C++ standard. I don't want to do
> this because this seems to be significant effort and is probably
> error prone (I'm not really familiar with the code and TMP code is
> hard to adapt). And we may have to repeat it for future HB upgrades.
> ? 2.? Upgrade compilers: This is possible on AIX. We'd need to
> backport some build changes and use xlclang++. But I guess there's no
> solaris studio available which can compile it. Note that the original
> bug was blocked by JEP 362: Deprecate the Solaris and SPARC Ports.
> ? 3.? Use configure flag --with-harfbuzz=system on the problematic
> platforms. Disadvantage: All machines require new enough version of
> libharfbuzz installed.
> ? 4.? Skip JDK-8247872 backport. Oracle must have had a reason for
> backporting it to 11.0.11-oracle, so some jdk11u users will probably
> want to have it at least on the main platforms.
> 
> Any comments or ideas will be appreciated.
> 
> Best regards,
> Martin
> 
> 
> [1] Resolution steps:
> - Manually delete hb-dsalgs.hh.
> - Awt2dLibraries.gmk is at a different location in 11u.
> - Integrate a few hunks manually due to minor adaptations for Solaris
> build: see 
> http://cr.openjdk.java.net/~mdoerr/8247872_harfbuzz_11u/8247872_harfbuzz_failing_hunks.txt
> - Add HARFBUZZ_CFLAGS := -std=c++11 to Awt2dLibraries.gmk.
> 
> [2] Supported compilers:
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
> 



From jwilhelm at openjdk.java.net  Thu Jan  7 20:45:15 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 7 Jan 2021 20:45:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: Merge jdk16
Message-ID: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description
 - 8251200: False positive messages about missing comments for serialization
 - 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days
 - 8259075: Update the copyright notice in the files generated by CLDR Converter tool
 - 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes
 - 8258558: Revert changes for JDK-8252505 and related issues
 - 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition
 - 8259007: This test printed a blank page
 - 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0e6de4eb...bbd6426f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1989&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/1989/files
  Stats: 2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1989.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1989/head:pull/1989

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

From jwilhelm at openjdk.java.net  Thu Jan  7 21:21:57 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 7 Jan 2021 21:21:57 GMT
Subject: [OpenJDK 2D-Dev] Integrated: Merge jdk16
In-Reply-To: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com>
References: <02vnbZrSN2O7CorWeOmmETnD8eNM9ebzDlkuVSO5HPs=.bf19f127-43d1-4e1f-85eb-3ffa97908b21@github.com>
Message-ID: <g7HsOL7HlE5kiLX6yzRNwvx5XNa7P_bh7ZlqKQgSMhM=.de687feb-4dbe-428e-9552-fa4b54dc2e04@github.com>

On Thu, 7 Jan 2021 20:40:49 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 555641ed
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/555641ed
Stats:     2957 lines in 68 files changed: 751 ins; 2142 del; 64 mod

Merge

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

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

From christoph.langer at sap.com  Thu Jan  7 22:41:38 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 7 Jan 2021 22:41:38 +0000
Subject: [OpenJDK 2D-Dev] [11u] Backport of 8247872: Upgrade HarfBuzz to
 the latest 2.7.2
In-Reply-To: <32e197f5ec5fce10f1aaf06260c54b0328c7549b.camel@redhat.com>
References: <AM4PR02MB3057E76ABABD7ED56E2F7CFF9AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <32e197f5ec5fce10f1aaf06260c54b0328c7549b.camel@redhat.com>
Message-ID: <AM4PR02MB31389CB17EAFBB97EDFAF7CE8AAF0@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

is there any other reason why harfbuzz 2.7.2 needs to be backported to OpenJDK 11 beyond the fact that Oracle did it?

I think both, having to uplift compiler requirements and/or requiring additional system dependencies, would be a price too high to pay for this. And modifying the code to work without c++11 features doesn't seem feasible.

Just my .02? at this point...

Best regards
Christoph

> -----Original Message-----
> From: 2d-dev <2d-dev-retn at openjdk.java.net> On Behalf Of Severin
> Gehwolf
> Sent: Donnerstag, 7. Januar 2021 18:32
> To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-
> dev at openjdk.java.net; 2d-dev at openjdk.java.net
> Subject: Re: [OpenJDK 2D-Dev] [11u] Backport of 8247872: Upgrade HarfBuzz
> to the latest 2.7.2
> 
> On Thu, 2021-01-07 at 17:16 +0000, Doerr, Martin wrote:
> > Hi,
> >
> > I've created a jdk11u backport of JDK-8247872: Upgrade HarfBuzz to
> > the latest 2.7.2
> > http://cr.openjdk.java.net/~mdoerr/8247872_harfbuzz_11u/webrev.00/
> >
> > I had to resolve it a bit manually [1].
> > However, the main problem is that it heavily uses C++11, so easiest
> > solution is to add HARFBUZZ_CFLAGS := -std=c++11.
> > This works for all supported compilers [2] except xlC on AIX and sun
> > studio on Solaris.
> 
> We are building vanilla JDK 11 builds with gcc 4.4.7 which doesn't
> support the -std=c++11 option. We've had issues in that area before.
> See JDK-8256557.
> 
> Thanks,
> Severin
> 
> > I could envision different solutions:
> >
> > ? 1.? Change code to work with older C++ standard. I don't want to do
> > this because this seems to be significant effort and is probably
> > error prone (I'm not really familiar with the code and TMP code is
> > hard to adapt). And we may have to repeat it for future HB upgrades.
> > ? 2.? Upgrade compilers: This is possible on AIX. We'd need to
> > backport some build changes and use xlclang++. But I guess there's no
> > solaris studio available which can compile it. Note that the original
> > bug was blocked by JEP 362: Deprecate the Solaris and SPARC Ports.
> > ? 3.? Use configure flag --with-harfbuzz=system on the problematic
> > platforms. Disadvantage: All machines require new enough version of
> > libharfbuzz installed.
> > ? 4.? Skip JDK-8247872 backport. Oracle must have had a reason for
> > backporting it to 11.0.11-oracle, so some jdk11u users will probably
> > want to have it at least on the main platforms.
> >
> > Any comments or ideas will be appreciated.
> >
> > Best regards,
> > Martin
> >
> >
> > [1] Resolution steps:
> > - Manually delete hb-dsalgs.hh.
> > - Awt2dLibraries.gmk is at a different location in 11u.
> > - Integrate a few hunks manually due to minor adaptations for Solaris
> > build: see
> >
> http://cr.openjdk.java.net/~mdoerr/8247872_harfbuzz_11u/8247872_harfb
> uzz_failing_hunks.txt
> > - Add HARFBUZZ_CFLAGS := -std=c++11 to Awt2dLibraries.gmk.
> >
> > [2] Supported compilers:
> > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
> >
> 


From clanger at openjdk.java.net  Thu Jan  7 22:55:08 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Thu, 7 Jan 2021 22:55:08 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] Integrated: 8258484: AIX build fails in
 Harfbuzz with XLC 16.01.0000.0006
Message-ID: <ECFyNO7fquQPHE7w1U3l3xABUiXk9fQm6_Mx3gL5AcE=.5e9cdf40-a96a-4861-a047-f6aefc6fa5e3@github.com>

8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006

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

Commit messages:
 - Backport 3f9f86f0d3f918b9955ba6ba73c9c58ae8fcf7cb

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

PR: https://git.openjdk.java.net/jdk16/pull/95

From clanger at openjdk.java.net  Thu Jan  7 22:55:08 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Thu, 7 Jan 2021 22:55:08 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] Integrated: 8258484: AIX build fails in
 Harfbuzz with XLC 16.01.0000.0006
In-Reply-To: <ECFyNO7fquQPHE7w1U3l3xABUiXk9fQm6_Mx3gL5AcE=.5e9cdf40-a96a-4861-a047-f6aefc6fa5e3@github.com>
References: <ECFyNO7fquQPHE7w1U3l3xABUiXk9fQm6_Mx3gL5AcE=.5e9cdf40-a96a-4861-a047-f6aefc6fa5e3@github.com>
Message-ID: <wobzFtS7tbTGBl4FvYyE3ly9LyXssoLCO-Y5uwmKYJs=.57a6c3db-2835-49aa-91b7-5f5b68f5b06d@github.com>

On Thu, 7 Jan 2021 22:47:35 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006

This pull request has now been integrated.

Changeset: 677802d2
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/677802d2
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006

Backport-of: 3f9f86f0d3f918b9955ba6ba73c9c58ae8fcf7cb

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

PR: https://git.openjdk.java.net/jdk16/pull/95

From aph at redhat.com  Fri Jan  8 09:44:23 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 8 Jan 2021 09:44:23 +0000
Subject: [OpenJDK 2D-Dev] [11u] Backport of 8247872: Upgrade HarfBuzz to
 the latest 2.7.2
In-Reply-To: <AM4PR02MB31389CB17EAFBB97EDFAF7CE8AAF0@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3057E76ABABD7ED56E2F7CFF9AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <32e197f5ec5fce10f1aaf06260c54b0328c7549b.camel@redhat.com>
 <AM4PR02MB31389CB17EAFBB97EDFAF7CE8AAF0@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <46127723-fc47-1526-99da-6fb48af2a3ee@redhat.com>

On 1/7/21 10:41 PM, Langer, Christoph wrote:
> Hi,
> 
> is there any other reason why harfbuzz 2.7.2 needs to be backported to OpenJDK 11 beyond the fact that Oracle did it?
> 
> I think both, having to uplift compiler requirements and/or requiring additional system dependencies, would be a price too high to pay for this. And modifying the code to work without c++11 features doesn't seem feasible.

It does seem like a lot of work. maybe the issue is that HarfBuzz is no
longer supported, and wouldn't get critical updates.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From prr at openjdk.java.net  Sat Jan  9 01:33:02 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 9 Jan 2021 01:33:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error handling in
 Cocoa code.
Message-ID: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>

Proposed updates to JNI error handling.

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

Commit messages:
 - 8259343: [macOS] Update JNI error handling in Cocoa code.
 - 8259343: [macOS] Update JNI error handling in Cocoa code.

Changes: https://git.openjdk.java.net/jdk/pull/1967/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1967&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259343
  Stats: 73 lines in 8 files changed: 58 ins; 1 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1967.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1967/head:pull/1967

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

From serb at openjdk.java.net  Sat Jan  9 01:33:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Jan 2021 01:33:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code.
In-Reply-To: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
Message-ID: <apA2NKaqAGFPpZFDE_aUNby4Hatr84-NHvC6h8aZ3hg=.9846d8c7-1d40-44df-849f-8dae026a2184@github.com>

On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race <prr at openjdk.org> wrote:

> Proposed updates to JNI error handling.

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180:

> 178:  * nature of the problem that has been detected and how survivable it is.
> 179:  */
> 180: #define CHECK_EXCEPTION() \

Since this macro does not try to return from the outer code we can change it to the method?

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182:

> 180: #define CHECK_EXCEPTION() \
> 181:     if ((*env)->ExceptionOccurred(env) != NULL) { \
> 182:         if ([NSThread isMainThread] == YES) { \

Isn't it is a similar code to the
https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334
Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code.

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:

> 39:        NSLog(@"%@",[NSThread callStackSymbols]); \
> 40:        if ([NSThread isMainThread] == NO) { \
> 41:            JNU_ThrowInternalError(env, "Bad JNI Lookup"); \

It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception.

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

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

From prr at openjdk.java.net  Sat Jan  9 01:33:05 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 9 Jan 2021 01:33:05 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code.
In-Reply-To: <apA2NKaqAGFPpZFDE_aUNby4Hatr84-NHvC6h8aZ3hg=.9846d8c7-1d40-44df-849f-8dae026a2184@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <apA2NKaqAGFPpZFDE_aUNby4Hatr84-NHvC6h8aZ3hg=.9846d8c7-1d40-44df-849f-8dae026a2184@github.com>
Message-ID: <ir477S2rZ9EMJrMnGC03Btym_AAfbSIpq-PP2_ZOVAs=.417c238e-321a-47ab-a1a3-c6b17a51ad09@github.com>

On Thu, 7 Jan 2021 00:35:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Proposed updates to JNI error handling.
>
> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180:
> 
>> 178:  * nature of the problem that has been detected and how survivable it is.
>> 179:  */
>> 180: #define CHECK_EXCEPTION() \
> 
> Since this macro does not try to return from the outer code we can change it to the method?

But then "env" would need to be passed explicitly. I don't think the churn is worth it.
And a method would then need a .m or .c file ...

> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:
> 
>> 39:        NSLog(@"%@",[NSThread callStackSymbols]); \
>> 40:        if ([NSThread isMainThread] == NO) { \
>> 41:            JNU_ThrowInternalError(env, "Bad JNI Lookup"); \
> 
> It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception.

I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown.
Is that what you are tihinking ?

And separately, with either the current code of clearing exceptions or the change here to  the practice of throwing NSException on seeing a Java Exception I think it very unlikely.

> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182:
> 
>> 180: #define CHECK_EXCEPTION() \
>> 181:     if ((*env)->ExceptionOccurred(env) != NULL) { \
>> 182:         if ([NSThread isMainThread] == YES) { \
> 
> Isn't it is a similar code to the
> https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334
> Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code.

In my testing that code does not get called.  The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see.

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

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

From serb at openjdk.java.net  Sat Jan  9 01:33:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Jan 2021 01:33:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code.
In-Reply-To: <ir477S2rZ9EMJrMnGC03Btym_AAfbSIpq-PP2_ZOVAs=.417c238e-321a-47ab-a1a3-c6b17a51ad09@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <apA2NKaqAGFPpZFDE_aUNby4Hatr84-NHvC6h8aZ3hg=.9846d8c7-1d40-44df-849f-8dae026a2184@github.com>
 <ir477S2rZ9EMJrMnGC03Btym_AAfbSIpq-PP2_ZOVAs=.417c238e-321a-47ab-a1a3-c6b17a51ad09@github.com>
Message-ID: <HOE-My-P-WXeuEEFEM0JKtb1dkAuTpo7oUQPShZXuoc=.63ba6ba0-ecb2-48b6-b319-fa1870c4a506@github.com>

On Fri, 8 Jan 2021 02:40:58 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:
>> 
>>> 39:        NSLog(@"%@",[NSThread callStackSymbols]); \
>>> 40:        if ([NSThread isMainThread] == NO) { \
>>> 41:            JNU_ThrowInternalError(env, "Bad JNI Lookup"); \
>> 
>> It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception.
>
> I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown.
> Is that what you are tihinking ?
> 
> And separately, with either the current code of clearing exceptions or the change here to  the practice of throwing NSException on seeing a Java Exception I think it very unlikely.

Then how we get NoSuchMethodError here? https://bugs.openjdk.java.net/browse/JDK-8259232?
https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetMethodID
Calling Instance Methods: GetMethodID
RETURNS:
    Returns a method ID, or NULL if the specified method cannot be found.
THROWS:
    NoSuchMethodError: if the specified method cannot be found.
    ExceptionInInitializerError: if the class initializer fails due to an exception.
    OutOfMemoryError: if the system runs out of memory.

Same for fields:
https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetFieldID

>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180:
>> 
>>> 178:  * nature of the problem that has been detected and how survivable it is.
>>> 179:  */
>>> 180: #define CHECK_EXCEPTION() \
>> 
>> Since this macro does not try to return from the outer code we can change it to the method?
>
> But then "env" would need to be passed explicitly. I don't think the churn is worth it.
> And a method would then need a .m or .c file ...

But that could be merged to the CallXXXMethod and placed somewhere in the libosxapp

>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182:
>> 
>>> 180: #define CHECK_EXCEPTION() \
>>> 181:     if ((*env)->ExceptionOccurred(env) != NULL) { \
>>> 182:         if ([NSThread isMainThread] == YES) { \
>> 
>> Isn't it is a similar code to the
>> https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334
>> Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code.
>
> In my testing that code does not get called.  The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see.

That code for sure should be called, it is even improved recently by JDK-8255681
I'll check how it was intended to work.

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

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

From prr at openjdk.java.net  Sat Jan  9 01:33:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 9 Jan 2021 01:33:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code.
In-Reply-To: <HOE-My-P-WXeuEEFEM0JKtb1dkAuTpo7oUQPShZXuoc=.63ba6ba0-ecb2-48b6-b319-fa1870c4a506@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <apA2NKaqAGFPpZFDE_aUNby4Hatr84-NHvC6h8aZ3hg=.9846d8c7-1d40-44df-849f-8dae026a2184@github.com>
 <ir477S2rZ9EMJrMnGC03Btym_AAfbSIpq-PP2_ZOVAs=.417c238e-321a-47ab-a1a3-c6b17a51ad09@github.com>
 <HOE-My-P-WXeuEEFEM0JKtb1dkAuTpo7oUQPShZXuoc=.63ba6ba0-ecb2-48b6-b319-fa1870c4a506@github.com>
Message-ID: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com>

On Fri, 8 Jan 2021 04:40:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> But then "env" would need to be passed explicitly. I don't think the churn is worth it.
>> And a method would then need a .m or .c file ...
>
> But that could be merged to the CallXXXMethod and placed somewhere in the libosxapp

You mean those methods  or macros that we already discussed and I explained why I do not want to do that ?
This is a small update for error checking not revisiting everything done before.

>> I don't think "most" of the time is very likely. JNI lookup failures don't cause exceptions to be thrown.
>> Is that what you are tihinking ?
>> 
>> And separately, with either the current code of clearing exceptions or the change here to  the practice of throwing NSException on seeing a Java Exception I think it very unlikely.
>
> Then how we get NoSuchMethodError here? https://bugs.openjdk.java.net/browse/JDK-8259232?
> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetMethodID
> Calling Instance Methods: GetMethodID
> RETURNS:
>     Returns a method ID, or NULL if the specified method cannot be found.
> THROWS:
>     NoSuchMethodError: if the specified method cannot be found.
>     ExceptionInInitializerError: if the class initializer fails due to an exception.
>     OutOfMemoryError: if the system runs out of memory.
> 
> Same for fields:
> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetFieldID

Ok. I will only create my own if none is pending.

>> In my testing that code does not get called.  The new code does. So the old code could probably be deleted as useless but it is also harmless and just maybe it'll catch something else, even if it isn't doing anything that I can see.
>
> That code for sure should be called, it is even improved recently by JDK-8255681
> I'll check how it was intended to work.

I hadn't noticed that line - and definintely not realised it was recent.
I suppose he must have had a way to trigger it.
But I don't think it hurts to have both.

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

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

From prr at openjdk.java.net  Sat Jan  9 01:33:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 9 Jan 2021 01:33:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code.
In-Reply-To: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
Message-ID: <bxYFyZ1EUw3SL1jDAysjaVXGb_K_ZcRaM1sBAcR-toE=.c91c5d45-315e-4f00-83af-8c035baefd87@github.com>

On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race <prr at openjdk.org> wrote:

> Proposed updates to JNI error handling.

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46:

> 44:               if ((*env)->ExceptionOccurred(env) != NULL) { \
> 45:                   (*env)->ExceptionDescribe(env); \
> 46:               } \

So the update here is that if we are not on the appkit thread, make sure a java exception is thrown.
If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using
describe which prints it.

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

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

From lbourges at openjdk.java.net  Sat Jan  9 09:13:03 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 9 Jan 2021 09:13:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates with
 a dashed Stroke can cause Java to hang
Message-ID: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>

This is my first fix proposal on this bug:
- added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
- fix all RenderingEngine implementations in java.desktop module
- MarlinRenderingEngine now use the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
- LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.

I will write a new test class in follow-up commits to validate the bug fix.

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

Commit messages:
 - fixed whitespaces
 - jdk-7018932.0

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

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

From lbourges at openjdk.java.net  Sat Jan  9 09:50:19 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 9 Jan 2021 09:50:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v2]
In-Reply-To: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
Message-ID: <186HTlXruOKA44_Y4m-Ruo36mGXKdambtsvbIt5m0fo=.4991139b-5e2f-4d07-b45a-8479dea183aa@github.com>

> This is my first fix proposal on this bug:
> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
> - fix all RenderingEngine implementations in java.desktop module
> - MarlinRenderingEngine now use the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
> 
> I will write a new test class in follow-up commits to validate the bug fix.

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  fixed RenderingEngine.Tracer impl + added DrawingTest7018932 test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/4d04b85d..5785f866

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

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

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

From lbourges at openjdk.java.net  Sat Jan  9 10:05:11 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sat, 9 Jan 2021 10:05:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v3]
In-Reply-To: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
Message-ID: <kCXRcd2k4lnYbe-N_uwEC48SiGfB_-v4L2bb3xf6vgc=.fa7baf5e-799b-4fb2-9c62-dfc184c4782e@github.com>

> This is my first fix proposal on this bug:
> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
> - fix all RenderingEngine implementations in java.desktop module
> - MarlinRenderingEngine now use the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
> 
> I will write a new test class in follow-up commits to validate the bug fix.

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  fixed white spaces

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/5785f866..4df9ab38

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

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

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

From serb at openjdk.java.net  Sat Jan  9 10:20:21 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 9 Jan 2021 10:20:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255710: Opensource unit/regression tests for
 CMM
Message-ID: <i8M-UwO4DhCDj8mYUKI9qYcnHsj3ABG6j2h8z139leo=.3394484b-21bf-4ba7-af69-db492772ff46@github.com>

A few tests for the CMM moved to the open repo.

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

Commit messages:
 - Initial fix

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

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

From pbansal at openjdk.java.net  Sat Jan  9 12:53:11 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 9 Jan 2021 12:53:11 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259237: Demo selection changes with
 left/right arrow key. No need to press space for selection.
Message-ID: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>

Please review a fix for jdk16

Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.

Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.

This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 

Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.

Before fix for JDK-8249548
JToggleButton: 
For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
JRadioButton: 
For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"

After fix for JDK-8249548
JToggleButton:
For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
JRadioButton:
For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".

After current fix:
JToggleButton:
For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
JRadioButton:
For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"

I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

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

Commit messages:
 - 8259237: Demo selection changes with left/right arrow key. No need to press space for selection.

Changes: https://git.openjdk.java.net/jdk16/pull/99/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=99&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259237
  Stats: 375 lines in 4 files changed: 350 ins; 20 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/99.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/99/head:pull/99

PR: https://git.openjdk.java.net/jdk16/pull/99

From serb at openjdk.java.net  Sun Jan 10 02:49:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 10 Jan 2021 02:49:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v3]
In-Reply-To: <kCXRcd2k4lnYbe-N_uwEC48SiGfB_-v4L2bb3xf6vgc=.fa7baf5e-799b-4fb2-9c62-dfc184c4782e@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <kCXRcd2k4lnYbe-N_uwEC48SiGfB_-v4L2bb3xf6vgc=.fa7baf5e-799b-4fb2-9c62-dfc184c4782e@github.com>
Message-ID: <HupadamDHN_pDhFc0I04VFUvFoHBCQSkdHRpgXJI_KM=.579fd6d4-371e-40e2-a6ea-8b8d1008b88d@github.com>

On Sat, 9 Jan 2021 10:05:11 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> This is my fix proposal to this bug:
>> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
>> - fixed all RenderingEngine implementations in java.desktop module
>> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
>> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
>> 
>> I wrote a new test class to validate the bug fix.
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed white spaces

src/java.desktop/share/classes/sun/java2d/pipe/RenderingEngine.java line 257:

> 255:      * @since 17
> 256:      */
> 257:     public abstract void strokeTo(Shape src,

I think we need to clarify the backward compatibility of this change.
 - If we would like to support the old marlin version via "-Dsun.java2d.renderer" option in jdk17 then adding the new abstract method to this interface breaks this possibility. To support that this method should be made default and call the old strokeTo method.
 - If support for the old marlin library is not necessary then we could drop the old method from this interface(but preserve it in the MarlinRenderingEngine to have the same marlin codebase), it won't be used anyway.

src/java.desktop/share/classes/sun/java2d/pipe/LoopPipe.java line 273:

> 271:                 (sg2d.strokeHint != SunHints.INTVAL_STROKE_PURE);
> 272: 
> 273: // No clipping (pre-jdk17)

This code is not a part of the marlin, so exists only in the jdk17. Do we need these commented lines here?

test/jdk/sun/java2d/marlin/DrawingTest7018932.java line 42:

> 40:  * @run main DrawingTest7018932
> 41:  */
> 42: public class DrawingTest7018932 extends JPanel {

This will work only in the headful environment, I suggest something like this:
/*
 * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

import java.awt.BasicStroke;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import java.awt.Stroke;
import java.awt.geom.Line2D;
import java.awt.image.BufferedImage;

import static java.awt.image.BufferedImage.TYPE_INT_ARGB_PRE;

/*
 * @test
 * @bug 7018932
 * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled by Marlin renderer)
 */
public final class StrokedLinePerf {

    public static void main(String[] args) {
        BufferedImage bi = new BufferedImage(400, 400, TYPE_INT_ARGB_PRE);
        test(bi, true);
        test(bi, false);
    }

    private static void test(BufferedImage bi, boolean useAA) {
        Graphics2D g2d = bi.createGraphics();
        long start = System.nanoTime();

        if (useAA) {
            g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
                    RenderingHints.VALUE_ANTIALIAS_ON);
        } else {
            g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
                    RenderingHints.VALUE_ANTIALIAS_OFF);
        }

        Stroke stroke = new BasicStroke(2.0f, 1, 0, 1.0f, new float[]{0.0f, 4.0f}, 0.0f);
        g2d.setStroke(stroke);

        //Large values to trigger crash / infinite loop.
        g2d.draw(new Line2D.Double(4.0, 1.794369841E9, 567.0, -2.147483648E9));

        System.out.println("Test duration= " + (1e-6 * (System.nanoTime() - start)) + " ms.");
        g2d.dispose();
    }
}

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

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

From lbourges at openjdk.java.net  Sun Jan 10 11:19:56 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 10 Jan 2021 11:19:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v3]
In-Reply-To: <HupadamDHN_pDhFc0I04VFUvFoHBCQSkdHRpgXJI_KM=.579fd6d4-371e-40e2-a6ea-8b8d1008b88d@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <kCXRcd2k4lnYbe-N_uwEC48SiGfB_-v4L2bb3xf6vgc=.fa7baf5e-799b-4fb2-9c62-dfc184c4782e@github.com>
 <HupadamDHN_pDhFc0I04VFUvFoHBCQSkdHRpgXJI_KM=.579fd6d4-371e-40e2-a6ea-8b8d1008b88d@github.com>
Message-ID: <tEShgThl7OchKd0HNqO6HvHJ22WWY-hbBw5KTUfcdzw=.dc77ccf7-4211-4195-944e-4f3b8793fe6c@github.com>

On Sun, 10 Jan 2021 02:20:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed white spaces
>
> src/java.desktop/share/classes/sun/java2d/pipe/RenderingEngine.java line 257:
> 
>> 255:      * @since 17
>> 256:      */
>> 257:     public abstract void strokeTo(Shape src,
> 
> I think we need to clarify the backward compatibility of this change.
>  - If we would like to support the old marlin version via "-Dsun.java2d.renderer" option in jdk17 then adding the new abstract method to this interface breaks this possibility. To support that this method should be made default and call the old strokeTo method.
>  - If support for the old marlin library is not necessary then we could drop the old method from this interface(but preserve it in the MarlinRenderingEngine to have the same marlin codebase), it won't be used anyway.

I like the first proposal: use default class method as RE is an abstract class.

> src/java.desktop/share/classes/sun/java2d/pipe/LoopPipe.java line 273:
> 
>> 271:                 (sg2d.strokeHint != SunHints.INTVAL_STROKE_PURE);
>> 272: 
>> 273: // No clipping (pre-jdk17)
> 
> This code is not a part of the marlin, so exists only in the jdk17. Do we need these commented lines here?

Will remove the comment

> test/jdk/sun/java2d/marlin/DrawingTest7018932.java line 42:
> 
>> 40:  * @run main DrawingTest7018932
>> 41:  */
>> 42: public class DrawingTest7018932 extends JPanel {
> 
> This will work only in the headful environment, I suggest something like this:
> /*
>  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com if you need additional information or have any
>  * questions.
>  */
> 
> import java.awt.BasicStroke;
> import java.awt.Graphics2D;
> import java.awt.RenderingHints;
> import java.awt.Stroke;
> import java.awt.geom.Line2D;
> import java.awt.image.BufferedImage;
> 
> import static java.awt.image.BufferedImage.TYPE_INT_ARGB_PRE;
> 
> /*
>  * @test
>  * @bug 7018932
>  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled by Marlin renderer)
>  */
> public final class StrokedLinePerf {
> 
>     public static void main(String[] args) {
>         BufferedImage bi = new BufferedImage(400, 400, TYPE_INT_ARGB_PRE);
>         test(bi, true);
>         test(bi, false);
>     }
> 
>     private static void test(BufferedImage bi, boolean useAA) {
>         Graphics2D g2d = bi.createGraphics();
>         long start = System.nanoTime();
> 
>         if (useAA) {
>             g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
>                     RenderingHints.VALUE_ANTIALIAS_ON);
>         } else {
>             g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
>                     RenderingHints.VALUE_ANTIALIAS_OFF);
>         }
> 
>         Stroke stroke = new BasicStroke(2.0f, 1, 0, 1.0f, new float[]{0.0f, 4.0f}, 0.0f);
>         g2d.setStroke(stroke);
> 
>         //Large values to trigger crash / infinite loop.
>         g2d.draw(new Line2D.Double(4.0, 1.794369841E9, 567.0, -2.147483648E9));
> 
>         System.out.println("Test duration= " + (1e-6 * (System.nanoTime() - start)) + " ms.");
>         g2d.dispose();
>     }
> }

Interesting, but BufferedImage rendering may use another java2d pipeline... so I will check if LoopPipe.getStrokedSpans() is used by your test code.

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

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

From lbourges at openjdk.java.net  Sun Jan 10 11:19:58 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 10 Jan 2021 11:19:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v3]
In-Reply-To: <tEShgThl7OchKd0HNqO6HvHJ22WWY-hbBw5KTUfcdzw=.dc77ccf7-4211-4195-944e-4f3b8793fe6c@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <kCXRcd2k4lnYbe-N_uwEC48SiGfB_-v4L2bb3xf6vgc=.fa7baf5e-799b-4fb2-9c62-dfc184c4782e@github.com>
 <HupadamDHN_pDhFc0I04VFUvFoHBCQSkdHRpgXJI_KM=.579fd6d4-371e-40e2-a6ea-8b8d1008b88d@github.com>
 <tEShgThl7OchKd0HNqO6HvHJ22WWY-hbBw5KTUfcdzw=.dc77ccf7-4211-4195-944e-4f3b8793fe6c@github.com>
Message-ID: <YFpT6UPf7q1p2dDy97AGPFYApESTkth_Miyh7Kl-aVU=.dd38054c-f436-4b6b-8460-fade4d9fdca0@github.com>

On Sun, 10 Jan 2021 11:16:51 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> test/jdk/sun/java2d/marlin/DrawingTest7018932.java line 42:
>> 
>>> 40:  * @run main DrawingTest7018932
>>> 41:  */
>>> 42: public class DrawingTest7018932 extends JPanel {
>> 
>> This will work only in the headful environment, I suggest something like this:
>> /*
>>  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>>  * under the terms of the GNU General Public License version 2 only, as
>>  * published by the Free Software Foundation.
>>  *
>>  * This code is distributed in the hope that it will be useful, but WITHOUT
>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>  * version 2 for more details (a copy is included in the LICENSE file that
>>  * accompanied this code).
>>  *
>>  * You should have received a copy of the GNU General Public License version
>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>  *
>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>  * or visit www.oracle.com if you need additional information or have any
>>  * questions.
>>  */
>> 
>> import java.awt.BasicStroke;
>> import java.awt.Graphics2D;
>> import java.awt.RenderingHints;
>> import java.awt.Stroke;
>> import java.awt.geom.Line2D;
>> import java.awt.image.BufferedImage;
>> 
>> import static java.awt.image.BufferedImage.TYPE_INT_ARGB_PRE;
>> 
>> /*
>>  * @test
>>  * @bug 7018932
>>  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled by Marlin renderer)
>>  */
>> public final class StrokedLinePerf {
>> 
>>     public static void main(String[] args) {
>>         BufferedImage bi = new BufferedImage(400, 400, TYPE_INT_ARGB_PRE);
>>         test(bi, true);
>>         test(bi, false);
>>     }
>> 
>>     private static void test(BufferedImage bi, boolean useAA) {
>>         Graphics2D g2d = bi.createGraphics();
>>         long start = System.nanoTime();
>> 
>>         if (useAA) {
>>             g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
>>                     RenderingHints.VALUE_ANTIALIAS_ON);
>>         } else {
>>             g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,
>>                     RenderingHints.VALUE_ANTIALIAS_OFF);
>>         }
>> 
>>         Stroke stroke = new BasicStroke(2.0f, 1, 0, 1.0f, new float[]{0.0f, 4.0f}, 0.0f);
>>         g2d.setStroke(stroke);
>> 
>>         //Large values to trigger crash / infinite loop.
>>         g2d.draw(new Line2D.Double(4.0, 1.794369841E9, 567.0, -2.147483648E9));
>> 
>>         System.out.println("Test duration= " + (1e-6 * (System.nanoTime() - start)) + " ms.");
>>         g2d.dispose();
>>     }
>> }
>
> Interesting, but BufferedImage rendering may use another java2d pipeline... so I will check if LoopPipe.getStrokedSpans() is used by your test code.

Moreover the bug was detected on both gdi & xrender native pipelines...

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

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

From pbansal at openjdk.java.net  Sun Jan 10 12:59:58 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sun, 10 Jan 2021 12:59:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255710: Opensource unit/regression tests
 for CMM
In-Reply-To: <i8M-UwO4DhCDj8mYUKI9qYcnHsj3ABG6j2h8z139leo=.3394484b-21bf-4ba7-af69-db492772ff46@github.com>
References: <i8M-UwO4DhCDj8mYUKI9qYcnHsj3ABG6j2h8z139leo=.3394484b-21bf-4ba7-af69-db492772ff46@github.com>
Message-ID: <dohAtGZlNmdlfJ4sBIJ5nSROsPD_JVByJy8eqQ5Yz88=.0cb6a48b-a5f1-4483-b14a-ec7cc34407d3@github.com>

On Sat, 9 Jan 2021 07:28:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> A few tests for the CMM moved to the open repo.

Marked as reviewed by pbansal (Reviewer).

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

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

From lbourges at openjdk.java.net  Sun Jan 10 21:00:17 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 10 Jan 2021 21:00:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v4]
In-Reply-To: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
Message-ID: <IaJG_Ret5DlMMiFwrnL4N6J6pZox8SR0EeefM3zNuV4=.54228b67-1cff-41f0-a386-ac83d58ded33@github.com>

> This is my fix proposal to this bug:
> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
> - fixed all RenderingEngine implementations in java.desktop module
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
> 
> I wrote a new test class to validate the bug fix.

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  Fixed RenderingEngine.strokeTo(clip) to call by default former method.
  Fixed CurveClipSplitter (float) to use double-precision for higher
  accuracy.
  Improved StrokedLineTest to use only bufferedimage rendering.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/4df9ab38..3ae23d94

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

  Stats: 216 lines in 4 files changed: 74 ins; 112 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2013.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2013/head:pull/2013

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

From lbourges at openjdk.java.net  Sun Jan 10 21:00:18 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 10 Jan 2021 21:00:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v3]
In-Reply-To: <YFpT6UPf7q1p2dDy97AGPFYApESTkth_Miyh7Kl-aVU=.dd38054c-f436-4b6b-8460-fade4d9fdca0@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <kCXRcd2k4lnYbe-N_uwEC48SiGfB_-v4L2bb3xf6vgc=.fa7baf5e-799b-4fb2-9c62-dfc184c4782e@github.com>
 <HupadamDHN_pDhFc0I04VFUvFoHBCQSkdHRpgXJI_KM=.579fd6d4-371e-40e2-a6ea-8b8d1008b88d@github.com>
 <tEShgThl7OchKd0HNqO6HvHJ22WWY-hbBw5KTUfcdzw=.dc77ccf7-4211-4195-944e-4f3b8793fe6c@github.com>
 <YFpT6UPf7q1p2dDy97AGPFYApESTkth_Miyh7Kl-aVU=.dd38054c-f436-4b6b-8460-fade4d9fdca0@github.com>
Message-ID: <dRcEDDu5_tWdknOWyzdUvJgju9DNZYYPWKinMDgLIMc=.826dc105-c863-469c-b22f-112be27e9853@github.com>

On Sun, 10 Jan 2021 11:17:49 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> Interesting, but BufferedImage rendering may use another java2d pipeline... so I will check if LoopPipe.getStrokedSpans() is used by your test code.
>
> Moreover the bug was detected on both gdi & xrender native pipelines...

Confirmed:
* useAA=true:
sun.java2d.marlin.MarlinRenderingEngine.getAATileGenerator(java.awt.geom.Line2D$Double, AffineTransform[[1.0, 0.0, 0.0], [0.0, 1.0, 0.0]], Region[[0, 0 => 400, 400]], java.awt.BasicStroke at 110e1781, wide, normalized)
* useAA=false:
sun.java2d.marlin.MarlinRenderingEngine.strokeTo(java.awt.geom.Line2D$Double, AffineTransform[[1.0, 0.0, 0.0], [0.0, 1.0, 0.0]], Region[[0, 0 => 400, 400]], java.awt.BasicStroke at 110e1781, wide, normalized, non-AA, sun.java2d.pipe.ShapeSpanIterator)

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

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

From lbourges at openjdk.java.net  Sun Jan 10 21:04:12 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 10 Jan 2021 21:04:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v5]
In-Reply-To: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
Message-ID: <IjvxvmLWRMNZVNrjr4mP5omlaN_tevVcFKlr2TNSubQ=.d0790719-0271-4027-ab94-3ff2116eadd0@github.com>

> This is my fix proposal to this bug:
> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
> - fixed all RenderingEngine implementations in java.desktop module
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
> 
> I wrote a new test class to validate the bug fix.

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  Removed comments in LoopPipe.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/3ae23d94..02cc2cb1

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

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

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

From lbourges at openjdk.java.net  Sun Jan 10 21:10:13 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 10 Jan 2021 21:10:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v6]
In-Reply-To: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
Message-ID: <bMtjeFqtHpIUDj9W2dc7-n9tmdKqjltLfXtcBe4M3LE=.f356fbfb-4ea6-48e4-bd5a-05fb0c87c9d3@github.com>

> This is my fix proposal to this bug:
> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
> - fixed all RenderingEngine implementations in java.desktop module
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
> 
> I wrote a new test class to validate the bug fix.

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo BasicSroke to BasicStroke

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/02cc2cb1..0592f191

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2013&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2013&range=04-05

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

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

From herrick at openjdk.java.net  Mon Jan 11 01:56:56 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 11 Jan 2021 01:56:56 GMT
Subject: [OpenJDK 2D-Dev] Withdrawn: JDK-8189198: Add "forRemoval = true" to
 Applet APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <W1UkrX-Pby-7JTwj25LZVphkdeZ1merEib-AWXWU93Q=.79b50980-33b7-4b1e-8141-6e6939819f1f@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

This pull request has been closed without being integrated.

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

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

From prr at openjdk.java.net  Mon Jan 11 02:59:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 11 Jan 2021 02:59:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255710: Opensource unit/regression tests
 for CMM
In-Reply-To: <i8M-UwO4DhCDj8mYUKI9qYcnHsj3ABG6j2h8z139leo=.3394484b-21bf-4ba7-af69-db492772ff46@github.com>
References: <i8M-UwO4DhCDj8mYUKI9qYcnHsj3ABG6j2h8z139leo=.3394484b-21bf-4ba7-af69-db492772ff46@github.com>
Message-ID: <IgVFK_WeP0KCi-K6l5ocBzXNy6h8f8lZv0JdqLB8m3Q=.f774e167-7abd-413b-8dd4-5425d5dd6bb8@github.com>

On Sat, 9 Jan 2021 07:28:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> A few tests for the CMM moved to the open repo.

Marked as reviewed by prr (Reviewer).

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

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

From serb at openjdk.java.net  Mon Jan 11 06:07:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 11 Jan 2021 06:07:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code.
In-Reply-To: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
Message-ID: <KBdnAHTTGVer6xdH3dlkdiOj704XooQlOtRaz9RNAmw=.777e653d-f040-47dd-a246-ef12599fbe79@github.com>

On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race <prr at openjdk.org> wrote:

> Proposed updates to JNI error handling.

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:

> 39:        NSLog(@"%@",[NSThread callStackSymbols]); \
> 40:        if ([NSThread isMainThread] == NO) { \
> 41:            if ((*env)->ExceptionOccurred(env) == NULL) { \

Not sure that the check for ExceptionOccurred is needed, in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example :
https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357

Note that the exception in the static initializer is fatal for the application.

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

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

From serb at openjdk.java.net  Mon Jan 11 06:07:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 11 Jan 2021 06:07:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code.
In-Reply-To: <bxYFyZ1EUw3SL1jDAysjaVXGb_K_ZcRaM1sBAcR-toE=.c91c5d45-315e-4f00-83af-8c035baefd87@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <bxYFyZ1EUw3SL1jDAysjaVXGb_K_ZcRaM1sBAcR-toE=.c91c5d45-315e-4f00-83af-8c035baefd87@github.com>
Message-ID: <7RahvO2lHhxOAhcIdk2_pqtsbqdelLHRSXeAin2ZnQY=.0aaa2356-c382-46e7-83be-99ec143ee8ff@github.com>

On Fri, 8 Jan 2021 19:05:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> Proposed updates to JNI error handling.
>
> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46:
> 
>> 44:               if ((*env)->ExceptionOccurred(env) != NULL) { \
>> 45:                   (*env)->ExceptionDescribe(env); \
>> 46:               } \
> 
> So the update here is that if we are not on the appkit thread, make sure a java exception is thrown.
> If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using
> describe which prints it.

I read the logic of the method differently, probably the wrong indents?
  - If we are not on the toolkit thread then
    - Check ExceptionOccurred -> throw JNU_ThrowInternalError if needed or check exception again ->call ExceptionDescribe
  - NSException raise at the end.

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

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

From serb at openjdk.java.net  Mon Jan 11 06:08:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 11 Jan 2021 06:08:00 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code.
In-Reply-To: <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <apA2NKaqAGFPpZFDE_aUNby4Hatr84-NHvC6h8aZ3hg=.9846d8c7-1d40-44df-849f-8dae026a2184@github.com>
 <ir477S2rZ9EMJrMnGC03Btym_AAfbSIpq-PP2_ZOVAs=.417c238e-321a-47ab-a1a3-c6b17a51ad09@github.com>
 <HOE-My-P-WXeuEEFEM0JKtb1dkAuTpo7oUQPShZXuoc=.63ba6ba0-ecb2-48b6-b319-fa1870c4a506@github.com>
 <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com>
Message-ID: <FO9q-wdnW-RaGHfPhh7XMac-QA7Gy1ls_n2AbeC2Yfg=.0ada85db-543d-4792-b2e5-584c7095f581@github.com>

On Fri, 8 Jan 2021 19:17:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> That code for sure should be called, it is even improved recently by JDK-8255681
>> I'll check how it was intended to work.
>
> I hadn't noticed that line - and definintely not realised it was recent.
> I suppose he must have had a way to trigger it.
> But I don't think it hurts to have both.

I just tried to understand why we need to complicate this, to me, it is unclear why handling the same errors in the NSApplicationAWT.m does not work.

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

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

From serb at openjdk.java.net  Mon Jan 11 06:13:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 11 Jan 2021 06:13:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v4]
In-Reply-To: <IaJG_Ret5DlMMiFwrnL4N6J6pZox8SR0EeefM3zNuV4=.54228b67-1cff-41f0-a386-ac83d58ded33@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <IaJG_Ret5DlMMiFwrnL4N6J6pZox8SR0EeefM3zNuV4=.54228b67-1cff-41f0-a386-ac83d58ded33@github.com>
Message-ID: <xfYi5By0DZDwV11sCb17hB54clBDfKvm-O0ENaHENLU=.d2d74b6d-406f-4f6e-b04e-836cf64922e8@github.com>

On Sun, 10 Jan 2021 21:00:17 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> This is my fix proposal to this bug:
>> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
>> - fixed all RenderingEngine implementations in java.desktop module
>> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
>> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
>> 
>> I wrote a new test class to validate the bug fix.
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed RenderingEngine.strokeTo(clip) to call by default former method.
>   Fixed CurveClipSplitter (float) to use double-precision for higher
>   accuracy.
>   Improved StrokedLineTest to use only bufferedimage rendering.

src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java line 902:

> 900: 
> 901:         // clip rectangle (ymin, ymax, xmin, xmax) including padding:
> 902:         final double[] clipRectPad = new double[4];

It does not seem related to this fix? Or an updated test uncovered this?

test/jdk/sun/java2d/marlin/StrokedLinePerf.java line 37:

> 35:  * @bug 7018932
> 36:  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled by Marlin renderer)
> 37:  * @run main DrawingTest7018932

typo DrawingTest7018932 -> StrokedLinePerf

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

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

From serb at openjdk.java.net  Mon Jan 11 08:19:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 11 Jan 2021 08:19:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259522: Apply java.io.Serial annotations in
 java.desktop
Message-ID: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>

Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.

This annotation can be applied to these methods in the module:

    private void writeObject(java.io.ObjectOutputStream stream) throws IOException
    private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
    private void readObjectNoData() throws ObjectStreamException
    ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
    ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
    private static final ObjectStreamField[] serialPersistentFields
    private static final long serialVersionUID

Notes:
  - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
  - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.

A similar fix was implemented for java.base module as well:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html

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

Commit messages:
 - Update TextAttribute.java
 - Update readResolve
 - Update writeReplace
 - Update readObject
 - Update writeObject
 - Update serialPersistentFields
 - Update serialVersionUID

Changes: https://git.openjdk.java.net/jdk/pull/2020/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2020&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259522
  Stats: 3426 lines in 343 files changed: 2268 ins; 287 del; 871 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2020.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2020/head:pull/2020

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

From psadhukhan at openjdk.java.net  Mon Jan 11 08:22:59 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 11 Jan 2021 08:22:59 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259237: Demo selection changes
 with left/right arrow key. No need to press space for selection.
In-Reply-To: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
Message-ID: <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>

On Sat, 9 Jan 2021 12:47:48 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

I guess you did not run jtreg job with latest problemlist as it did not run
javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java
javax/swing/JRadioButton/8075609/bug8075609.java
javax/swing/JRadioButton/8033699/bug8033699.java
Please see this test pass with your change as some of them used to fail  after JDK-8226892 which was reworked by fix of  JDK-8249548

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 228:

> 226:         if (listener != null) {
> 227:             b.removeMouseListener(listener);
> 228:             b.removeMouseListener(listener);

Why are we removing same listener twice?

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Mon Jan 11 08:37:57 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 08:37:57 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259237: Demo selection changes
 with left/right arrow key. No need to press space for selection.
In-Reply-To: <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
Message-ID: <vaJ3RBhtAW_-WcNRfOPBdWyD_lbiv0XB_74eHpfx9fE=.8c3f0471-cb2c-4256-a748-f0ec98411091@github.com>

On Mon, 11 Jan 2021 08:05:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please review a fix for jdk16
>> 
>> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
>> 
>> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
>> 
>> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
>> 
>> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
>> 
>> Before fix for JDK-8249548
>> JToggleButton: 
>> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
>> JRadioButton: 
>> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
>> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
>> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
>> 
>> After fix for JDK-8249548
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> JRadioButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
>> 
>> After current fix:
>> JToggleButton:
>> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
>> JRadioButton:
>> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
>> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
>> 
>> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 228:
> 
>> 226:         if (listener != null) {
>> 227:             b.removeMouseListener(listener);
>> 228:             b.removeMouseListener(listener);
> 
> Why are we removing same listener twice?

I just rolled back the changes I did in this file in JDK-8249548. Looks like this was has been there for some time. See the file in commit made in this file before JDK-8249548 https://github.com/openjdk/jdk/blob/c18080fef714949221c8ddabc4e23d409575c3d3/src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java. 
But yes, it should not be done and I will remove it and update the PR.

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From lbourges at openjdk.java.net  Mon Jan 11 09:00:27 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 11 Jan 2021 09:00:27 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v7]
In-Reply-To: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
Message-ID: <4aknOPMpu8K2B0lEwOamMg97QWh7SFF97UyeI1nhxAY=.d1d841a5-2687-41a7-9c7f-d14f37d7128e@github.com>

> This is my fix proposal to this bug:
> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
> - fixed all RenderingEngine implementations in java.desktop module
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
> 
> I wrote a new test class to validate the bug fix.

Laurent Bourg?s has updated the pull request incrementally with two additional commits since the last revision:

 - fixed copyright year
 - removed invalid jtreg test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2013/files
  - new: https://git.openjdk.java.net/jdk/pull/2013/files/0592f191..f5dea906

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2013&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2013&range=05-06

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

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

From lbourges at openjdk.java.net  Mon Jan 11 09:00:28 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 11 Jan 2021 09:00:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v4]
In-Reply-To: <xfYi5By0DZDwV11sCb17hB54clBDfKvm-O0ENaHENLU=.d2d74b6d-406f-4f6e-b04e-836cf64922e8@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <IaJG_Ret5DlMMiFwrnL4N6J6pZox8SR0EeefM3zNuV4=.54228b67-1cff-41f0-a386-ac83d58ded33@github.com>
 <xfYi5By0DZDwV11sCb17hB54clBDfKvm-O0ENaHENLU=.d2d74b6d-406f-4f6e-b04e-836cf64922e8@github.com>
Message-ID: <pNa47w0sNWrUbvwMEFWp_KWHes5Q3jl8yXth0NiPoSA=.401d3b6a-a3e2-46e6-9c35-5bb9912a3881@github.com>

On Mon, 11 Jan 2021 06:09:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed RenderingEngine.strokeTo(clip) to call by default former method.
>>   Fixed CurveClipSplitter (float) to use double-precision for higher
>>   accuracy.
>>   Improved StrokedLineTest to use only bufferedimage rendering.
>
> test/jdk/sun/java2d/marlin/StrokedLinePerf.java line 37:
> 
>> 35:  * @bug 7018932
>> 36:  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled by Marlin renderer)
>> 37:  * @run main DrawingTest7018932
> 
> typo DrawingTest7018932 -> StrokedLinePerf

Removed invalid test

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

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

From lbourges at openjdk.java.net  Mon Jan 11 09:04:00 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 11 Jan 2021 09:04:00 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v4]
In-Reply-To: <xfYi5By0DZDwV11sCb17hB54clBDfKvm-O0ENaHENLU=.d2d74b6d-406f-4f6e-b04e-836cf64922e8@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <IaJG_Ret5DlMMiFwrnL4N6J6pZox8SR0EeefM3zNuV4=.54228b67-1cff-41f0-a386-ac83d58ded33@github.com>
 <xfYi5By0DZDwV11sCb17hB54clBDfKvm-O0ENaHENLU=.d2d74b6d-406f-4f6e-b04e-836cf64922e8@github.com>
Message-ID: <pnJj0CkCU622uVxIVZHLDjfY4P7_F5IylXbpB3RnlUA=.0d26d95f-3a51-4099-be0d-c65257f9e59b@github.com>

On Mon, 11 Jan 2021 06:08:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed RenderingEngine.strokeTo(clip) to call by default former method.
>>   Fixed CurveClipSplitter (float) to use double-precision for higher
>>   accuracy.
>>   Improved StrokedLineTest to use only bufferedimage rendering.
>
> src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java line 902:
> 
>> 900: 
>> 901:         // clip rectangle (ymin, ymax, xmin, xmax) including padding:
>> 902:         final double[] clipRectPad = new double[4];
> 
> It does not seem related to this fix? Or an updated test uncovered this?

This fix in Marlin (float) renderer is needed as this numerical precision issue was triggered by the StrokedLinePerf using the MarlinRenderingEngine. It is very similar to DTransformingPathConsumer2D (but reuse was not trivial).

I propose to remove the MarlinRenderingEngine (single-precision) in a follow-up issue ... to simplify the maintenance.

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

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

From ihse at openjdk.java.net  Mon Jan 11 09:23:11 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 11 Jan 2021 09:23:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module [v4]
In-Reply-To: <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
Message-ID: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>

On Mon, 4 Jan 2021 21:20:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Update comment refering to "make" dir
>>  - Move new symbols to jdk.compiler
>>  - Merge branch 'master' into shuffle-data
>>  - Move macosxicons from share to macosx
>>  - Move to share/data, and move jdwp.spec to java.se
>>  - Update references in test
>>  - Step 2: Update references
>>  - First stage, move actual data files
>
> Marked as reviewed by prr (Reviewer).

This PR is not stale; it's just still waiting for input from @AlanBateman.

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

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

From pbansal at openjdk.java.net  Mon Jan 11 09:52:18 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 09:52:18 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259237: Demo selection changes
 with left/right arrow key. No need to press space for selection. [v2]
In-Reply-To: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
Message-ID: <DuaFVSJxGNy9Ckys-vthZvKgVji4pJLBYejlj6PNaPY=.50f196e5-37b6-490f-aec2-a237b1479ce9@github.com>

> Please review a fix for jdk16
> 
> Issue: In SwingSet2, if the user navigates through the demos, the demo gets selected/starts on pressing left/right key only. There is no need to press the "space" key. Earlier, on pressing the left/right key, only demo icon used to get focused and user needed to press the "space" to actually select a demo.
> 
> Cause: The SwingSet2 has JToggleButtons added to a ButtonGroup. Each JToggleButton has an AbstractAction set on it, which loads the demo. Earlier, when the user pressed Left/Right button, only the selected button used to change. The Action set on JToggleButton used to perform only  on pressing the "Space" button. Now, the Action is performed on navigating the JToggleButtons using Left/Right keys without the need to press the "space" key.
> 
> This issue is a side effect of fix done for https://bugs.openjdk.java.net/browse/JDK-8249548. The issues fixed in JDK-8249548 were not present in JRadioButton as there was code available to handle it in AquaButtonRadioUI and BasicRadioButtonUI. The fix done for JDK-8249548 moved duplicate code from AquaButtonRadioUI and BasicRadioButtonUI and moved it to BasicButtonUI, so this code is available for JToggleButton and JRadioButton for all L&Fs. This was wrong as there is a difference in behaviour for JRadioButtons added to ButtonGroup for AquaL&F and other L&Fs. In AquaL&F, the AbstractAction set on JRadioButton is not performed on button selection and user has to press "space". In other L&Fs, the AbstractAction is performed on selection of Button itself without the need to press "space". 
> 
> Fix: The current change fixes the issue in present bug and keeps the fixes done in JDK-8249548. Following is the behaviour of JToggleButton and JRadioButton for different L&Fs before JDK-8249548 fix, after JDK-8249548 fix and after current fix.
> 
> Before fix for JDK-8249548
> JToggleButton: 
> For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
> JRadioButton: 
> For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup. 
> For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
> For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"
> 
> After fix for JDK-8249548
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> JRadioButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups and the AbstractAction set is performed without the need to press "space".
> 
> After current fix:
> JToggleButton:
> For all L&Fs, user can navigate/select the buttons added to ButtonGroups.  User needs to press "space" to perform the set AbstractAction.
> JRadioButton:
> For AquaL&F, the behaviour before JDK-8249548 is restored, so user needs to press the "space" to perform the set Action.
> For all other L&Fs (including Synth L&F), the behaviour is same. User can navigate/select the buttons added to ButtonGroups and set Action is performed without pressing "space"
> 
> I have run mach5 jobs with full jtreg/jck and all looks good. Links in JBS. The test TestButtonGroupFocusTraversal.java is modified such that it fails without current fix and passes after the fix. The fix also should be verified by running SwingSet2.

Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:

  Remove duplicate call to remove listener

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/99/files
  - new: https://git.openjdk.java.net/jdk16/pull/99/files/903ffcbd..724f5999

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

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From kizune at openjdk.java.net  Mon Jan 11 11:19:04 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 11 Jan 2021 11:19:04 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259237: Demo selection changes
 with left/right arrow key. No need to press space for selection. [v2]
In-Reply-To: <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
Message-ID: <LtHsnZIbspthwSFnQyQBaPIGdW9TL_GWZkLMaWb7hqg=.abc44411-51f7-40da-90aa-a2b9bec1c753@github.com>

On Mon, 11 Jan 2021 08:20:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove duplicate call to remove listener
>
> I guess you did not run jtreg job with latest problemlist as it did not run
> javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java
> javax/swing/JRadioButton/8075609/bug8075609.java
> javax/swing/JRadioButton/8033699/bug8033699.java
> Please see this test pass with your change as some of them used to fail  after JDK-8226892 which was reworked by fix of  JDK-8249548

Quick question: why we special casing JRadioButton case? Is there any reason we should call the action on them?

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From pbansal at openjdk.java.net  Mon Jan 11 12:01:04 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 11 Jan 2021 12:01:04 GMT
Subject: [OpenJDK 2D-Dev] [jdk16] RFR: 8259237: Demo selection changes
 with left/right arrow key. No need to press space for selection. [v2]
In-Reply-To: <LtHsnZIbspthwSFnQyQBaPIGdW9TL_GWZkLMaWb7hqg=.abc44411-51f7-40da-90aa-a2b9bec1c753@github.com>
References: <AnbmACNb-yMh6Wlhth-01ektPdDHGPVs3KjbOwRKIbU=.93f65f9d-6488-4631-966d-3676332f6e30@github.com>
 <lGIg_uPD9j5pfmbMr9wvGZQiVw6tSN69WcSx5kvatv4=.3500a5b5-7f89-48a5-b605-c4b7c2319dab@github.com>
 <LtHsnZIbspthwSFnQyQBaPIGdW9TL_GWZkLMaWb7hqg=.abc44411-51f7-40da-90aa-a2b9bec1c753@github.com>
Message-ID: <BNoH7zJqMQRdKZWUmU3Ubdq797NAglCVP0T8BhSzuko=.ff2bf736-d95d-4e71-83d9-83ca5a60e148@github.com>

On Mon, 11 Jan 2021 11:16:02 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Quick question: why we special casing JRadioButton case? Is there any reason we should call the action on them?

This was the behaviour which was there before JDK-8249548 for JRadioButton and I am just reverting to it. As explained in the PR description, the behaviour before JDK-8249548 was as below

Before fix for JDK-8249548
JToggleButton:
    For all L&Fs, user can not navigate/select the buttons added to ButtonGroup properly as mentioned in the JDK-8249548.
JRadioButton:
    For Synth L&F (Nimbus L&F), user can not navigate/select the buttons added to ButtonGroup.
    For AquaL&F, user can select the buttons added to ButtonGroup by pressing left/right key and needs to press the "space" to perform the set Action.
    For Other L&Fs, user can select/navigate the buttons and the set Action is also performed without pressing "space"

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

PR: https://git.openjdk.java.net/jdk16/pull/99

From prr at openjdk.java.net  Mon Jan 11 17:52:19 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 11 Jan 2021 17:52:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v2]
In-Reply-To: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
Message-ID: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com>

> Proposed updates to JNI error handling.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8259343: [macOS] Update JNI error handling in Cocoa code.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1967/files
  - new: https://git.openjdk.java.net/jdk/pull/1967/files/0e745aa6..08a41150

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

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

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

From prr at openjdk.java.net  Mon Jan 11 17:52:19 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 11 Jan 2021 17:52:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v2]
In-Reply-To: <KBdnAHTTGVer6xdH3dlkdiOj704XooQlOtRaz9RNAmw=.777e653d-f040-47dd-a246-ef12599fbe79@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <KBdnAHTTGVer6xdH3dlkdiOj704XooQlOtRaz9RNAmw=.777e653d-f040-47dd-a246-ef12599fbe79@github.com>
Message-ID: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com>

On Mon, 11 Jan 2021 05:52:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Not sure that the check for ExceptionOccurred is needed, 
It may not be needed in practice but if the code path is never taken no harm ...

in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example :
> 
> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357
> 
> Note that the exception in the static initializer is fatal for the application.

Nothing new here.

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

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

From prr at openjdk.java.net  Mon Jan 11 17:52:20 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 11 Jan 2021 17:52:20 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v2]
In-Reply-To: <7RahvO2lHhxOAhcIdk2_pqtsbqdelLHRSXeAin2ZnQY=.0aaa2356-c382-46e7-83be-99ec143ee8ff@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <bxYFyZ1EUw3SL1jDAysjaVXGb_K_ZcRaM1sBAcR-toE=.c91c5d45-315e-4f00-83af-8c035baefd87@github.com>
 <7RahvO2lHhxOAhcIdk2_pqtsbqdelLHRSXeAin2ZnQY=.0aaa2356-c382-46e7-83be-99ec143ee8ff@github.com>
Message-ID: <IZqRM-RgqSAQ6_4tHj2tCXQW4qZD_2AgfFEDeLnCNas=.0f0782d9-75e9-4819-a4ef-35c0e6af5fdf@github.com>

On Mon, 11 Jan 2021 05:58:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 46:
>> 
>>> 44:               if ((*env)->ExceptionOccurred(env) != NULL) { \
>>> 45:                   (*env)->ExceptionDescribe(env); \
>>> 46:               } \
>> 
>> So the update here is that if we are not on the appkit thread, make sure a java exception is thrown.
>> If we are on the appkit thread, clear any java exception since it isn't going anywhere but do it using
>> describe which prints it.
>
> I read the logic of the method differently, probably the wrong indents?
>   - If we are not on the toolkit thread then
>     - Check ExceptionOccurred -> throw JNU_ThrowInternalError if needed or check exception again ->call ExceptionDescribe
>   - NSException raise at the end.

I have a paren in the wrong place ! I've pushed an update.

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

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

From prr at openjdk.java.net  Mon Jan 11 17:52:20 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 11 Jan 2021 17:52:20 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v2]
In-Reply-To: <FO9q-wdnW-RaGHfPhh7XMac-QA7Gy1ls_n2AbeC2Yfg=.0ada85db-543d-4792-b2e5-584c7095f581@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <apA2NKaqAGFPpZFDE_aUNby4Hatr84-NHvC6h8aZ3hg=.9846d8c7-1d40-44df-849f-8dae026a2184@github.com>
 <ir477S2rZ9EMJrMnGC03Btym_AAfbSIpq-PP2_ZOVAs=.417c238e-321a-47ab-a1a3-c6b17a51ad09@github.com>
 <HOE-My-P-WXeuEEFEM0JKtb1dkAuTpo7oUQPShZXuoc=.63ba6ba0-ecb2-48b6-b319-fa1870c4a506@github.com>
 <2MhWS44-i0zX8lt6BUh_dpOxsEQdYnifCB8dcqO_25E=.319e2c92-6bf1-40fa-86a6-5d9df8c6c27e@github.com>
 <FO9q-wdnW-RaGHfPhh7XMac-QA7Gy1ls_n2AbeC2Yfg=.0ada85db-543d-4792-b2e5-584c7095f581@github.com>
Message-ID: <3jqvTyJ_wKIDMURTmYQSbTCwUMcVRRvzvVekjS9Eem0=.866999d7-3542-4f3f-9e93-d6955b05a657@github.com>

On Mon, 11 Jan 2021 06:01:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I hadn't noticed that line - and definintely not realised it was recent.
>> I suppose he must have had a way to trigger it.
>> But I don't think it hurts to have both.
>
> I just tried to understand why we need to complicate this, to me, it is unclear why handling the same errors in the NSApplicationAWT.m does not work.

Because of the reason I've said before. That logging in NSApplication AWT is not being seen. Something is swallowing it. So I'd say if anything remove that logging and keep the new one but as I also said it isn't harmful to have provision in case it also logs some case we aren't catching.

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

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

From erikj at openjdk.java.net  Mon Jan 11 18:59:03 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 11 Jan 2021 18:59:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v2]
In-Reply-To: <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com>
Message-ID: <f2K6S9hW2Ulfj1ndEG583JsgV8sjOn157o99yaNGVIs=.bc5389bd-0257-42e3-826b-e58884db3267@github.com>

On Mon, 11 Jan 2021 17:52:19 GMT, Phil Race <prr at openjdk.org> wrote:

>> Proposed updates to JNI error handling.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8259343: [macOS] Update JNI error handling in Cocoa code.

make/modules/java.desktop/Lib.gmk line 96:

> 94:           $(call SET_SHARED_LIBRARY_ORIGIN), \
> 95:       LIBS := \
> 96:           -ljava \

There should be a dependency declaration added too. Something like this right after the SetupJdkLibrary macro call:

$(BUILD_LIBOSXAPP): $(call FindLib, java.base, java)

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

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

From prr at openjdk.java.net  Mon Jan 11 19:27:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 11 Jan 2021 19:27:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v3]
In-Reply-To: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
Message-ID: <yl8QAJHOzuJAYs-rkPbEezyfDPNMALFDTccVbJfTpD4=.22d5e0ea-52ce-4151-89cc-01ea0910a27f@github.com>

> Proposed updates to JNI error handling.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8259343: [macOS] Update JNI error handling in Cocoa code.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1967/files
  - new: https://git.openjdk.java.net/jdk/pull/1967/files/08a41150..913b37c2

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

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

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

From prr at openjdk.java.net  Mon Jan 11 19:27:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 11 Jan 2021 19:27:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v2]
In-Reply-To: <f2K6S9hW2Ulfj1ndEG583JsgV8sjOn157o99yaNGVIs=.bc5389bd-0257-42e3-826b-e58884db3267@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <5fPXj8SlcJcjfD9bwylmTZ7bR7Gia8CIDUFADlpcPAU=.6c25ea7c-89b8-4e70-8269-1cdb1bedb8d3@github.com>
 <f2K6S9hW2Ulfj1ndEG583JsgV8sjOn157o99yaNGVIs=.bc5389bd-0257-42e3-826b-e58884db3267@github.com>
Message-ID: <QQKB0R7UMBIsbBqIyfWttyfyqTmYPoyFqAm4NoEXfj4=.794dc1eb-e528-49ba-ad50-1daf561ad2be@github.com>

On Mon, 11 Jan 2021 18:56:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There should be a dependency declaration added too. Something like this right after the SetupJdkLibrary macro call:
> 
> $(BUILD_LIBOSXAPP): $(call FindLib, java.base, java)

Fixed.

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

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

From erikj at openjdk.java.net  Mon Jan 11 20:22:58 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 11 Jan 2021 20:22:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v3]
In-Reply-To: <yl8QAJHOzuJAYs-rkPbEezyfDPNMALFDTccVbJfTpD4=.22d5e0ea-52ce-4151-89cc-01ea0910a27f@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <yl8QAJHOzuJAYs-rkPbEezyfDPNMALFDTccVbJfTpD4=.22d5e0ea-52ce-4151-89cc-01ea0910a27f@github.com>
Message-ID: <9q6B-ZySWhc8qPfcn728cCehk_SSer-qtIhCJdI3sXg=.dce6e806-9858-481b-96a7-f27ed7d2bdb3@github.com>

On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> Proposed updates to JNI error handling.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8259343: [macOS] Update JNI error handling in Cocoa code.

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From serb at openjdk.java.net  Tue Jan 12 02:34:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 02:34:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v3]
In-Reply-To: <yl8QAJHOzuJAYs-rkPbEezyfDPNMALFDTccVbJfTpD4=.22d5e0ea-52ce-4151-89cc-01ea0910a27f@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <yl8QAJHOzuJAYs-rkPbEezyfDPNMALFDTccVbJfTpD4=.22d5e0ea-52ce-4151-89cc-01ea0910a27f@github.com>
Message-ID: <x-yVLk70TIHltJpF8zad1wBNebeuuKpYisG6qOQZy0o=.580cc036-a00f-46e6-b9bc-fb2d6d66a111@github.com>

On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> Proposed updates to JNI error handling.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8259343: [macOS] Update JNI error handling in Cocoa code.

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197:

> 195:          }  \
> 196:         if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \
> 197:             [NSException raise:NSGenericException format:@"Java Exception"]; \

How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output?

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

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

From serb at openjdk.java.net  Tue Jan 12 02:41:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 02:41:00 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v3]
In-Reply-To: <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <KBdnAHTTGVer6xdH3dlkdiOj704XooQlOtRaz9RNAmw=.777e653d-f040-47dd-a246-ef12599fbe79@github.com>
 <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com>
Message-ID: <QRiPblRChY6nz_4FQ2BTbr5YNLH_WR3jM6Z9oHZKuWs=.c96706fd-e34d-4bcd-9bd2-e4c2d199750b@github.com>

On Mon, 11 Jan 2021 17:09:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:
>> 
>>> 39:        NSLog(@"%@",[NSThread callStackSymbols]); \
>>> 40:        if ([NSThread isMainThread] == NO) { \
>>> 41:            if ((*env)->ExceptionOccurred(env) == NULL) { \
>> 
>> Not sure that the check for ExceptionOccurred is needed, in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example :
>> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357
>> 
>> Note that the exception in the static initializer is fatal for the application.
>
>> Not sure that the check for ExceptionOccurred is needed, 
> It may not be needed in practice but if the code path is never taken no harm ...
> 
> in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example :
>> 
>> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357
>> 
>> Note that the exception in the static initializer is fatal for the application.
> 
> Nothing new here.

The new thing here is that you check the result of the ExceptionOccurred if NULL is returned from the GetMethodID/etc, we usually never do it. If such checks are necessary then I'll create a separate bug to update other similar use cases.

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

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

From serb at openjdk.java.net  Tue Jan 12 07:00:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 07:00:05 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8255710: Opensource unit/regression
 tests for CMM
In-Reply-To: <i8M-UwO4DhCDj8mYUKI9qYcnHsj3ABG6j2h8z139leo=.3394484b-21bf-4ba7-af69-db492772ff46@github.com>
References: <i8M-UwO4DhCDj8mYUKI9qYcnHsj3ABG6j2h8z139leo=.3394484b-21bf-4ba7-af69-db492772ff46@github.com>
Message-ID: <x9nbiCGo2Rt2fvAqTwaQkO7hcztOXIMD_MWx6dPYNCE=.d58d0631-03c5-4a4e-82f7-be86911fa8cb@github.com>

On Sat, 9 Jan 2021 07:28:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> A few tests for the CMM moved to the open repo.

This pull request has now been integrated.

Changeset: 98ccfbf4
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/98ccfbf4
Stats:     457 lines in 8 files changed: 457 ins; 0 del; 0 mod

8255710: Opensource unit/regression tests for CMM

Reviewed-by: pbansal, prr

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

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

From psadhukhan at openjdk.java.net  Tue Jan 12 10:15:12 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Jan 2021 10:15:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout [v5]
In-Reply-To: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
Message-ID: <kCguuuMQnVE5ScNV_mhWg_o5caC0hftNYNqJW-hZn7E=.4af80d58-2dd3-4d5a-877a-fb3b4e83c053@github.com>

> Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Convert into manual test to overcome automatic printer selection issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1927/files
  - new: https://git.openjdk.java.net/jdk/pull/1927/files/8ed618f2..3ce4f066

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

  Stats: 64 lines in 1 file changed: 56 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1927.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1927/head:pull/1927

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

From serb at openjdk.java.net  Tue Jan 12 10:46:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 10:46:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <MeDghiRAR1ltL6XPZ42yo-D-_sDu_U7URPKy0UFE5ms=.753a74bd-6dc3-4c75-86f5-4e52dbad5383@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>
 <iPVjSL9JFFydXE3NBHgQq3jiMpZ1rhPZKEYB2G74jso=.e2e4c94a-d15d-4258-9c8d-9f078eb08a0b@github.com>
 <MeDghiRAR1ltL6XPZ42yo-D-_sDu_U7URPKy0UFE5ms=.753a74bd-6dc3-4c75-86f5-4e52dbad5383@github.com>
Message-ID: <LuKHXRnvXn723lNKXlajMNbolytBNu_FSaBgax-0zXg=.62b430d3-4339-4794-83d0-e0cba20aa697@github.com>

On Mon, 4 Jan 2021 09:23:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> IIUC, In windows there can be non-real printers like "Send To OneNote", "Fax" which falls in Printers/Scanner list but not exactly printer so PrinterException is not thrown.
>
>> IIUC, In windows there can be non-real printers like "Send To OneNote", "Fax" which falls in Printers/Scanner list but not exactly printer so PrinterException is not thrown.
> 
> I am not sure that the fax is related here, but the "printjob.print()" should throw such an exception if printjob.getPrintService() is null (so we do not have any useful printers). Do you have a chance to reproduce this bug?
> 
> BTW the suggestion in the JBS was to fail the test if no printers are found.

Not sure that one more manual test is needed, the run of the test marked by the printer keyword already required to have a configured printer. Otherwise, why do we need that keyword at all?

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

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

From psadhukhan at openjdk.java.net  Tue Jan 12 11:52:03 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 12 Jan 2021 11:52:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <LuKHXRnvXn723lNKXlajMNbolytBNu_FSaBgax-0zXg=.62b430d3-4339-4794-83d0-e0cba20aa697@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>
 <iPVjSL9JFFydXE3NBHgQq3jiMpZ1rhPZKEYB2G74jso=.e2e4c94a-d15d-4258-9c8d-9f078eb08a0b@github.com>
 <MeDghiRAR1ltL6XPZ42yo-D-_sDu_U7URPKy0UFE5ms=.753a74bd-6dc3-4c75-86f5-4e52dbad5383@github.com>
 <LuKHXRnvXn723lNKXlajMNbolytBNu_FSaBgax-0zXg=.62b430d3-4339-4794-83d0-e0cba20aa697@github.com>
Message-ID: <0G7k8bzAbfBeBX2PHWXDuSXBM0kk7tX6fT-nrMNiP0U=.a7cc5830-60a7-488f-9589-aac07c543473@github.com>

On Tue, 12 Jan 2021 10:44:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> IIUC, In windows there can be non-real printers like "Send To OneNote", "Fax" which falls in Printers/Scanner list but not exactly printer so PrinterException is not thrown.
>> 
>> I am not sure that the fax is related here, but the "printjob.print()" should throw such an exception if printjob.getPrintService() is null (so we do not have any useful printers). Do you have a chance to reproduce this bug?
>> 
>> BTW the suggestion in the JBS was to fail the test if no printers are found.
>
> Not sure that one more manual test is needed, the run of the test marked by the printer keyword already required to have a configured printer. Otherwise, why do we need that keyword at all?

That printer keyword seems to be just a hint/suggestion as it does not force user to do anything, so we can still get this kind of problem. Making it manual at least will let user choose which printer he actually wants to work with.

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

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

From lbourges at openjdk.java.net  Tue Jan 12 12:04:55 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 12 Jan 2021 12:04:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang
In-Reply-To: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
Message-ID: <KGRF93GASiUNpGHng4n0amt-tlZb637W97GZsDaRvbg=.e77b4655-ca24-4064-9f4d-6640ac0bdbe9@github.com>

On Sat, 9 Jan 2021 09:05:27 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> This is my fix proposal to this bug:
> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
> - fixed all RenderingEngine implementations in java.desktop module
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
> 
> I wrote a new test class to validate the bug fix.

Sergey, is it good now ?
I ran jtreg: OK.

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

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

From prr at openjdk.java.net  Tue Jan 12 17:28:58 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 12 Jan 2021 17:28:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v3]
In-Reply-To: <QRiPblRChY6nz_4FQ2BTbr5YNLH_WR3jM6Z9oHZKuWs=.c96706fd-e34d-4bcd-9bd2-e4c2d199750b@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <KBdnAHTTGVer6xdH3dlkdiOj704XooQlOtRaz9RNAmw=.777e653d-f040-47dd-a246-ef12599fbe79@github.com>
 <1-5L0YWqNPmuzpu1O1Q1chv5l1dGr55oEdQj4r9wyRg=.1addab94-3655-417d-8e03-1a621164502a@github.com>
 <QRiPblRChY6nz_4FQ2BTbr5YNLH_WR3jM6Z9oHZKuWs=.c96706fd-e34d-4bcd-9bd2-e4c2d199750b@github.com>
Message-ID: <M18-XWEU1N0UIiJcDiCSGjwJx_RYSv9tj_PoDQt0AsI=.361da7fc-a35e-4803-b454-7072176b4b7c@github.com>

On Tue, 12 Jan 2021 02:38:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Not sure that the check for ExceptionOccurred is needed, 
>> It may not be needed in practice but if the code path is never taken no harm ...
>> 
>> in all other places where we check the ref to methods/field we only check the return value, and if it is null then return immediately assuming that an exception is rased already, for example :
>>> 
>>> https://github.com/openjdk/jdk/blob/b72de3c5fc99f365e9fb25114ddd28eceddfa6e8/src/java.desktop/windows/native/libawt/windows/awt_Button.cpp#L357
>>> 
>>> Note that the exception in the static initializer is fatal for the application.
>> 
>> Nothing new here.
>
> The new thing here is that you check the result of the ExceptionOccurred if NULL is returned from the GetMethodID/etc, we usually never do it. If such checks are necessary then I'll create a separate bug to update other similar use cases.

Here I don't have immediate control over why this is being called.
So we could have null but no pending exception depending on what the caller did.
It won't be executed except in the rare case there's a problem so it certainly isn't causing overhead so what is the problem ?
I don't see a need to change other code unless there's a really good reason.

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

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

From prr at openjdk.java.net  Tue Jan 12 17:24:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 12 Jan 2021 17:24:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v3]
In-Reply-To: <x-yVLk70TIHltJpF8zad1wBNebeuuKpYisG6qOQZy0o=.580cc036-a00f-46e6-b9bc-fb2d6d66a111@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <yl8QAJHOzuJAYs-rkPbEezyfDPNMALFDTccVbJfTpD4=.22d5e0ea-52ce-4151-89cc-01ea0910a27f@github.com>
 <x-yVLk70TIHltJpF8zad1wBNebeuuKpYisG6qOQZy0o=.580cc036-a00f-46e6-b9bc-fb2d6d66a111@github.com>
Message-ID: <unCxsAV1VGHxUkCeniVhar213GLiHLcfZTy5asK2UYs=.b4d7e7b4-f95a-48c8-abce-f03c4b40bfcf@github.com>

On Tue, 12 Jan 2021 02:31:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8259343: [macOS] Update JNI error handling in Cocoa code.
>
> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197:
> 
>> 195:          }  \
>> 196:         if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \
>> 197:             [NSException raise:NSGenericException format:@"Java Exception"]; \
> 
> How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output?

See the bug assigned to you that I filed last month : https://bugs.openjdk.java.net/browse/JDK-8258797
This error should have been logged by that NSApplicationAWT code but was not (and I mean in JDK 16 as well before I started on this) and in JDK 17 it was seen only when adding the new logging.

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

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

From prr at openjdk.java.net  Tue Jan 12 18:47:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 12 Jan 2021 18:47:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v7]
In-Reply-To: <4aknOPMpu8K2B0lEwOamMg97QWh7SFF97UyeI1nhxAY=.d1d841a5-2687-41a7-9c7f-d14f37d7128e@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <4aknOPMpu8K2B0lEwOamMg97QWh7SFF97UyeI1nhxAY=.d1d841a5-2687-41a7-9c7f-d14f37d7128e@github.com>
Message-ID: <eggRmMfdkZ6h9UuH57LRLPAfb1ieO-BYZ62h4jn4l-c=.2d510165-6904-4aff-ab71-ad5b24014e5e@github.com>

On Mon, 11 Jan 2021 09:00:27 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> This is my fix proposal to this bug:
>> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
>> - fixed all RenderingEngine implementations in java.desktop module
>> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
>> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
>> 
>> I wrote a new test class to validate the bug fix.
>
> Laurent Bourg?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed copyright year
>  - removed invalid jtreg test

src/java.desktop/share/classes/sun/java2d/pipe/SpanShapeRenderer.java line 45:

> 43:  */
> 44: public abstract class SpanShapeRenderer implements ShapeDrawPipe {
> 45: 

I suppose this is just clean up when you happened to notice it wasn't used/

test/jdk/sun/java2d/marlin/StrokedLinePerf.java line 37:

> 35:  * @bug 7018932
> 36:  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled by Marlin renderer)
> 37:  * @run main/othervm/timeout=10 -Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine StrokedLinePerf

I hope 10 seconds is enough for a stable test .. not connecting to the windowing system so maybe.

src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java line 902:

> 900: 
> 901:         // clip rectangle (ymin, ymax, xmin, xmax) including padding:
> 902:         final double[] clipRectPad = new double[4];

are all the changes to double needed for this ? Or just preparation for removing the float pipeline ?

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

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

From lbourges at openjdk.java.net  Tue Jan 12 18:48:00 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 12 Jan 2021 18:48:00 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v7]
In-Reply-To: <eggRmMfdkZ6h9UuH57LRLPAfb1ieO-BYZ62h4jn4l-c=.2d510165-6904-4aff-ab71-ad5b24014e5e@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <4aknOPMpu8K2B0lEwOamMg97QWh7SFF97UyeI1nhxAY=.d1d841a5-2687-41a7-9c7f-d14f37d7128e@github.com>
 <eggRmMfdkZ6h9UuH57LRLPAfb1ieO-BYZ62h4jn4l-c=.2d510165-6904-4aff-ab71-ad5b24014e5e@github.com>
Message-ID: <kYLStWeGpkk1xRYwA0YjBt6kY5eikeu7CyQ0hFK3ZJA=.1f24351c-d88e-4271-b0ad-9ab499c61ad2@github.com>

On Tue, 12 Jan 2021 18:40:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> Laurent Bourg?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed copyright year
>>  - removed invalid jtreg test
>
> src/java.desktop/share/classes/sun/java2d/pipe/SpanShapeRenderer.java line 45:
> 
>> 43:  */
>> 44: public abstract class SpanShapeRenderer implements ShapeDrawPipe {
>> 45: 
> 
> I suppose this is just clean up when you happened to notice it wasn't used/

Exactly.

> test/jdk/sun/java2d/marlin/StrokedLinePerf.java line 37:
> 
>> 35:  * @bug 7018932
>> 36:  * @summary fix LoopPipe.getStrokedSpans() performance (clipping enabled by Marlin renderer)
>> 37:  * @run main/othervm/timeout=10 -Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine StrokedLinePerf
> 
> I hope 10 seconds is enough for a stable test .. not connecting to the windowing system so maybe.

Each render ops take up to 100ms max on my machine, so the test runs in 0.5s on my machine.

Would you prefer 30s ? 
Timeout is mandatory to detect test failure = hanging ...

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

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

From lbourges at openjdk.java.net  Tue Jan 12 18:50:58 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 12 Jan 2021 18:50:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v7]
In-Reply-To: <eggRmMfdkZ6h9UuH57LRLPAfb1ieO-BYZ62h4jn4l-c=.2d510165-6904-4aff-ab71-ad5b24014e5e@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <4aknOPMpu8K2B0lEwOamMg97QWh7SFF97UyeI1nhxAY=.d1d841a5-2687-41a7-9c7f-d14f37d7128e@github.com>
 <eggRmMfdkZ6h9UuH57LRLPAfb1ieO-BYZ62h4jn4l-c=.2d510165-6904-4aff-ab71-ad5b24014e5e@github.com>
Message-ID: <JLtt_1xZZ4aH66-pDn0xzJugLgHvibGCqZqIZnPyqnA=.53f248f2-204b-40bb-88d6-522b6ca7e32a@github.com>

On Tue, 12 Jan 2021 18:43:36 GMT, Phil Race <prr at openjdk.org> wrote:

>> Laurent Bourg?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed copyright year
>>  - removed invalid jtreg test
>
> src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java line 902:
> 
>> 900: 
>> 901:         // clip rectangle (ymin, ymax, xmin, xmax) including padding:
>> 902:         final double[] clipRectPad = new double[4];
> 
> are all the changes to double needed for this ? Or just preparation for removing the float pipeline ?

These change are just enough to make MarlinRenderingEngine (float) pass the new test.
Later we will propose to remove the float pipeline.

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

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

From serb at openjdk.java.net  Tue Jan 12 18:59:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 18:59:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v7]
In-Reply-To: <4aknOPMpu8K2B0lEwOamMg97QWh7SFF97UyeI1nhxAY=.d1d841a5-2687-41a7-9c7f-d14f37d7128e@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <4aknOPMpu8K2B0lEwOamMg97QWh7SFF97UyeI1nhxAY=.d1d841a5-2687-41a7-9c7f-d14f37d7128e@github.com>
Message-ID: <UYVoc0fC5QSgrAk7I5-FOGQtPNBXBHGq2RWmqxRItkA=.d91ca7ec-3851-419c-b4aa-42cc42d3d4e0@github.com>

On Mon, 11 Jan 2021 09:00:27 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> This is my fix proposal to this bug:
>> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
>> - fixed all RenderingEngine implementations in java.desktop module
>> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
>> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
>> 
>> I wrote a new test class to validate the bug fix.
>
> Laurent Bourg?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed copyright year
>  - removed invalid jtreg test

Internal testing is fine, The fix looks good. Thank you for your contribution!

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

Marked as reviewed by serb (Reviewer).

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

From prr at openjdk.java.net  Tue Jan 12 19:39:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 12 Jan 2021 19:39:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 7018932 : Drawing very large coordinates
 with a dashed Stroke can cause Java to hang [v7]
In-Reply-To: <4aknOPMpu8K2B0lEwOamMg97QWh7SFF97UyeI1nhxAY=.d1d841a5-2687-41a7-9c7f-d14f37d7128e@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
 <4aknOPMpu8K2B0lEwOamMg97QWh7SFF97UyeI1nhxAY=.d1d841a5-2687-41a7-9c7f-d14f37d7128e@github.com>
Message-ID: <4CH0U2V4-EW6lrB_nPI5Mnu4frNzT_QsQvX4EIylJsY=.84a2da80-45ac-438d-95cd-27545ee89f2f@github.com>

On Mon, 11 Jan 2021 09:00:27 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> This is my fix proposal to this bug:
>> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
>> - fixed all RenderingEngine implementations in java.desktop module
>> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
>> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
>> 
>> I wrote a new test class to validate the bug fix.
>
> Laurent Bourg?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed copyright year
>  - removed invalid jtreg test

Marked as reviewed by prr (Reviewer).

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

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

From serb at openjdk.java.net  Tue Jan 12 20:06:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 20:06:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v3]
In-Reply-To: <yl8QAJHOzuJAYs-rkPbEezyfDPNMALFDTccVbJfTpD4=.22d5e0ea-52ce-4151-89cc-01ea0910a27f@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <yl8QAJHOzuJAYs-rkPbEezyfDPNMALFDTccVbJfTpD4=.22d5e0ea-52ce-4151-89cc-01ea0910a27f@github.com>
Message-ID: <9L-Z-lva8-afVWdri9YjO0wIM0nQ6H7IUOcruvNUToY=.33f942e9-23cb-43e7-a07d-b1fe64df4974@github.com>

On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> Proposed updates to JNI error handling.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8259343: [macOS] Update JNI error handling in Cocoa code.

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Tue Jan 12 20:06:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 20:06:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259343: [macOS] Update JNI error
 handling in Cocoa code. [v3]
In-Reply-To: <unCxsAV1VGHxUkCeniVhar213GLiHLcfZTy5asK2UYs=.b4d7e7b4-f95a-48c8-abce-f03c4b40bfcf@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
 <yl8QAJHOzuJAYs-rkPbEezyfDPNMALFDTccVbJfTpD4=.22d5e0ea-52ce-4151-89cc-01ea0910a27f@github.com>
 <x-yVLk70TIHltJpF8zad1wBNebeuuKpYisG6qOQZy0o=.580cc036-a00f-46e6-b9bc-fb2d6d66a111@github.com>
 <unCxsAV1VGHxUkCeniVhar213GLiHLcfZTy5asK2UYs=.b4d7e7b4-f95a-48c8-abce-f03c4b40bfcf@github.com>
Message-ID: <oeDxiDDECZBIs6exauZMVICqZOJAnam8SN00lB2db1o=.4d7d69c2-b346-4779-b125-06791b71ed7c@github.com>

On Tue, 12 Jan 2021 17:21:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 197:
>> 
>>> 195:          }  \
>>> 196:         if (getenv("JNU_NO_COCOA_EXCEPTION") == NULL) { \
>>> 197:             [NSException raise:NSGenericException format:@"Java Exception"]; \
>> 
>> How did you check that the logging in the NSApplication was swallowing? Both macro will throw the NSException on the toolkit thread now, does it mean that in both cases the logging in the NSApplication will be ignored/no output?
>
> See the bug assigned to you that I filed last month : https://bugs.openjdk.java.net/browse/JDK-8258797
> This error should have been logged by that NSApplicationAWT code but was not (and I mean in JDK 16 as well before I started on this) and in JDK 17 it was seen only when adding the new logging.

I have found it down to the absence of NSApplication#reportException() method and logging in it. Ok will update that code later in the separate update.

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

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

From prr at openjdk.java.net  Tue Jan 12 20:22:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 12 Jan 2021 20:22:57 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8259343: [macOS] Update JNI error
 handling in Cocoa code.
In-Reply-To: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
References: <pR4MaoD3fm_4XUGixQUSumN62F-Pb2lqeeMvwZkDSWw=.c39d4094-9149-418e-af2b-c9e24ac6557a@github.com>
Message-ID: <JYL07oi-D59cWnay8LD7pqJRXFQHdu4VRqiYGFXOTT0=.65a34d5f-83a5-46ae-a99a-368df61a9b8e@github.com>

On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race <prr at openjdk.org> wrote:

> Proposed updates to JNI error handling.

This pull request has now been integrated.

Changeset: d6a2105b
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d6a2105b
Stats:     75 lines in 8 files changed: 60 ins; 1 del; 14 mod

8259343: [macOS] Update JNI error handling in Cocoa code.

Reviewed-by: erikj, serb

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

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

From aivanov at openjdk.java.net  Tue Jan 12 20:25:56 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 12 Jan 2021 20:25:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259522: Apply java.io.Serial annotations
 in java.desktop
In-Reply-To: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
Message-ID: <UztmJrze0OeVjg6dEapP5V_nrHNSw4tpoLmh1gvDRMI=.8db78595-8929-43ea-8194-95989eca450f@github.com>

On Mon, 11 Jan 2021 06:21:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
> 
> This annotation can be applied to these methods in the module:
> 
>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>     private void readObjectNoData() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>     private static final ObjectStreamField[] serialPersistentFields
>     private static final long serialVersionUID
> 
> Notes:
>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
> 
> A similar fix was implemented for java.base module as well:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42:

> 40:      */
> 41:     @Serial
> 42:     private static final long serialVersionUID = 1L;

This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique?

src/java.desktop/share/classes/java/awt/image/RasterFormatException.java line 28:

> 26: package java.awt.image;
> 27: 
> 28: 

Suggestion:


In the majority of classes, there's only one empty line between package declaration and the first import statement.

src/java.desktop/share/classes/java/awt/image/ImagingOpException.java line 28:

> 26: package java.awt.image;
> 27: 
> 28: 

Suggestion:

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

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

From serb at openjdk.java.net  Tue Jan 12 20:42:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 20:42:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259522: Apply java.io.Serial annotations
 in java.desktop [v2]
In-Reply-To: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
Message-ID: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>

> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
> 
> This annotation can be applied to these methods in the module:
> 
>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>     private void readObjectNoData() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>     private static final ObjectStreamField[] serialPersistentFields
>     private static final long serialVersionUID
> 
> Notes:
>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
> 
> A similar fix was implemented for java.base module as well:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html

Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
   
   Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
   
   Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2020/files
  - new: https://git.openjdk.java.net/jdk/pull/2020/files/2e50a258..502c1a40

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

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

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

From serb at openjdk.java.net  Tue Jan 12 20:42:19 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Jan 2021 20:42:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259522: Apply java.io.Serial annotations
 in java.desktop [v2]
In-Reply-To: <UztmJrze0OeVjg6dEapP5V_nrHNSw4tpoLmh1gvDRMI=.8db78595-8929-43ea-8194-95989eca450f@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <UztmJrze0OeVjg6dEapP5V_nrHNSw4tpoLmh1gvDRMI=.8db78595-8929-43ea-8194-95989eca450f@github.com>
Message-ID: <jEKeQUNA-jwXnAiKoNZHHZn98Qhrudsp4JEw42uyZOg=.51107fd8-8634-4db8-8628-f9c79171d399@github.com>

On Tue, 12 Jan 2021 11:29:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
>>    
>>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
>>    
>>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>
> src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42:
> 
>> 40:      */
>> 41:     @Serial
>> 42:     private static final long serialVersionUID = 1L;
> 
> This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique?

I think it is "quite" unique, the "1L" is used from the beginning. It is just different from the value which could be generated by the "serialver" but still should work fine.

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

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

From lbourges at openjdk.java.net  Tue Jan 12 20:54:57 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Tue, 12 Jan 2021 20:54:57 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 7018932 : Drawing very large
 coordinates with a dashed Stroke can cause Java to hang
In-Reply-To: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
References: <tCsBsEWXN5yLl71lFoSFGAcJ2kurQqE8EdbLmaVXAnE=.cfc235da-39db-4c05-b1e3-05a54abe9c64@github.com>
Message-ID: <vFSrEFp_koy5C3kl6bfbt-QGTsjmohpi35TqxTvHdKo=.ea6b04c4-dc4e-41c7-b49c-0e451222c697@github.com>

On Sat, 9 Jan 2021 09:05:27 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> This is my fix proposal to this bug:
> - added new method strokeTo(... Region clip ...) in the abstract RenderingEngine class
> - fixed all RenderingEngine implementations in java.desktop module
> - MarlinRenderingEngine now uses the clip region to roughly & quickly clip the given shape in strokeTo(clip) 
> - LoopPipe.getStrokeSpans() uses the new strokeTo(clip) method to get good performance with huge dashed shapes.
> 
> I wrote a new test class to validate the bug fix.

This pull request has now been integrated.

Changeset: e4df2098
Author:    Laurent Bourg?s <lbourges at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e4df2098
Stats:     345 lines in 7 files changed: 307 ins; 1 del; 37 mod

7018932: Drawing very large coordinates with a dashed Stroke can cause Java to hang

Reviewed-by: serb, prr

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

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

From aivanov at openjdk.java.net  Tue Jan 12 21:58:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 12 Jan 2021 21:58:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259522: Apply java.io.Serial annotations
 in java.desktop [v2]
In-Reply-To: <jEKeQUNA-jwXnAiKoNZHHZn98Qhrudsp4JEw42uyZOg=.51107fd8-8634-4db8-8628-f9c79171d399@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <UztmJrze0OeVjg6dEapP5V_nrHNSw4tpoLmh1gvDRMI=.8db78595-8929-43ea-8194-95989eca450f@github.com>
 <jEKeQUNA-jwXnAiKoNZHHZn98Qhrudsp4JEw42uyZOg=.51107fd8-8634-4db8-8628-f9c79171d399@github.com>
Message-ID: <eHpId3lh9IG_0cG0uspjUi6kCrxfYgVYUSbb3XSQiQU=.5e6df1db-b584-4630-be4b-26f0d1be955c@github.com>

On Tue, 12 Jan 2021 20:36:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java line 42:
>> 
>>> 40:      */
>>> 41:     @Serial
>>> 42:     private static final long serialVersionUID = 1L;
>> 
>> This is the standard wording, yet should it mention the serialization is between the same versions only because the value of serialVersionUID is not unique?
>
> I think it is "quite" unique, the "1L" is used from the beginning. It is just different from the value which could be generated by the "serialver" but still should work fine.

Okay. There are several classes which extend this one, all of them use the same 1L value which makes it not "quite" unique.

Changing the values at this time presents more risks than benefits.

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

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

From serb at openjdk.java.net  Wed Jan 13 02:58:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Jan 2021 02:58:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <0G7k8bzAbfBeBX2PHWXDuSXBM0kk7tX6fT-nrMNiP0U=.a7cc5830-60a7-488f-9589-aac07c543473@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>
 <iPVjSL9JFFydXE3NBHgQq3jiMpZ1rhPZKEYB2G74jso=.e2e4c94a-d15d-4258-9c8d-9f078eb08a0b@github.com>
 <MeDghiRAR1ltL6XPZ42yo-D-_sDu_U7URPKy0UFE5ms=.753a74bd-6dc3-4c75-86f5-4e52dbad5383@github.com>
 <LuKHXRnvXn723lNKXlajMNbolytBNu_FSaBgax-0zXg=.62b430d3-4339-4794-83d0-e0cba20aa697@github.com>
 <0G7k8bzAbfBeBX2PHWXDuSXBM0kk7tX6fT-nrMNiP0U=.a7cc5830-60a7-488f-9589-aac07c543473@github.com>
Message-ID: <UbK8pbOwobr_pVhGGhP5zcHIkQK4bAkyV2kyphJDgFM=.4a2c5db4-ba1a-4499-bde6-8dffd9473e98@github.com>

On Tue, 12 Jan 2021 11:49:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Not sure that one more manual test is needed, the run of the test marked by the printer keyword already required to have a configured printer. Otherwise, why do we need that keyword at all?
>
> That printer keyword seems to be just a hint/suggestion as it does not force user to do anything, so we can still get this kind of problem. Making it manual at least will let user choose which printer he actually wants to work with.

That's not a hint, it is similar to the headful keyword:
 - "headful" requires the proper configured system and accessible Desktop
 - "printer" requires the properly configured printer
https://github.com/openjdk/jdk/blob/0957d9eb1452b953c1a700ce7ea41155c22bc00e/test/jdk/TEST.ROOT#L14

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 04:20:01 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 04:20:01 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <UbK8pbOwobr_pVhGGhP5zcHIkQK4bAkyV2kyphJDgFM=.4a2c5db4-ba1a-4499-bde6-8dffd9473e98@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>
 <iPVjSL9JFFydXE3NBHgQq3jiMpZ1rhPZKEYB2G74jso=.e2e4c94a-d15d-4258-9c8d-9f078eb08a0b@github.com>
 <MeDghiRAR1ltL6XPZ42yo-D-_sDu_U7URPKy0UFE5ms=.753a74bd-6dc3-4c75-86f5-4e52dbad5383@github.com>
 <LuKHXRnvXn723lNKXlajMNbolytBNu_FSaBgax-0zXg=.62b430d3-4339-4794-83d0-e0cba20aa697@github.com>
 <0G7k8bzAbfBeBX2PHWXDuSXBM0kk7tX6fT-nrMNiP0U=.a7cc5830-60a7-488f-9589-aac07c543473@github.com>
 <UbK8pbOwobr_pVhGGhP5zcHIkQK4bAkyV2kyphJDgFM=.4a2c5db4-ba1a-4499-bde6-8dffd9473e98@github.com>
Message-ID: <3CgjxbTmr6kB2b1QV0iRbgYVjp7hlX0Gou2_BYRTths=.2c94ea40-87de-434a-b3af-b3f7dd102ad3@github.com>

On Wed, 13 Jan 2021 02:55:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> That printer keyword seems to be just a hint/suggestion as it does not force user to do anything, so we can still get this kind of problem. Making it manual at least will let user choose which printer he actually wants to work with.
>
> That's not a hint, it is similar to the headful keyword:
>  - "headful" requires the proper configured system and accessible Desktop
>  - "printer" requires the properly configured printer
> https://github.com/openjdk/jdk/blob/0957d9eb1452b953c1a700ce7ea41155c22bc00e/test/jdk/TEST.ROOT#L14

OK. But it's a keyword for jtreg, not useful for standalone execution as you have seen that one can get the problem running on freshly installed windows system. Making it manual will overcome standalone execution problem too.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 06:13:57 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 06:13:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259522: Apply java.io.Serial annotations
 in java.desktop [v2]
In-Reply-To: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
Message-ID: <0BeCSRlVfit-78buTvO8-tci6rZDhwsML4JXKzujLM8=.ff5ba622-5c99-4925-b690-5b348d0d0e18@github.com>

On Tue, 12 Jan 2021 20:42:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
>> 
>> This annotation can be applied to these methods in the module:
>> 
>>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>>     private void readObjectNoData() throws ObjectStreamException
>>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>>     private static final ObjectStreamField[] serialPersistentFields
>>     private static final long serialVersionUID
>> 
>> Notes:
>>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
>> 
>> A similar fix was implemented for java.base module as well:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html
>
> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

Why do we add serialVersionUID in some classes like DefaultMutableTreeNode.java but not in other swing classes?
Also, if this change is for stricter compile-time checking, shouldn't we remove @SuppressWarnings("serial") check?

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

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

From serb at openjdk.java.net  Wed Jan 13 06:30:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Jan 2021 06:30:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <3CgjxbTmr6kB2b1QV0iRbgYVjp7hlX0Gou2_BYRTths=.2c94ea40-87de-434a-b3af-b3f7dd102ad3@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>
 <iPVjSL9JFFydXE3NBHgQq3jiMpZ1rhPZKEYB2G74jso=.e2e4c94a-d15d-4258-9c8d-9f078eb08a0b@github.com>
 <MeDghiRAR1ltL6XPZ42yo-D-_sDu_U7URPKy0UFE5ms=.753a74bd-6dc3-4c75-86f5-4e52dbad5383@github.com>
 <LuKHXRnvXn723lNKXlajMNbolytBNu_FSaBgax-0zXg=.62b430d3-4339-4794-83d0-e0cba20aa697@github.com>
 <0G7k8bzAbfBeBX2PHWXDuSXBM0kk7tX6fT-nrMNiP0U=.a7cc5830-60a7-488f-9589-aac07c543473@github.com>
 <UbK8pbOwobr_pVhGGhP5zcHIkQK4bAkyV2kyphJDgFM=.4a2c5db4-ba1a-4499-bde6-8dffd9473e98@github.com>
 <3CgjxbTmr6kB2b1QV0iRbgYVjp7hlX0Gou2_BYRTths=.2c94ea40-87de-434a-b3af-b3f7dd102ad3@github.com>
Message-ID: <QtrPXaaIbMwwdDLNStKJlbQWoZC01Sis0Sxmk8h-plc=.d9ef4240-1eb7-4a49-ad19-00d197b64aa7@github.com>

On Wed, 13 Jan 2021 04:16:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> That's not a hint, it is similar to the headful keyword:
>>  - "headful" requires the proper configured system and accessible Desktop
>>  - "printer" requires the properly configured printer
>> https://github.com/openjdk/jdk/blob/0957d9eb1452b953c1a700ce7ea41155c22bc00e/test/jdk/TEST.ROOT#L14
>
> OK. But it's a keyword for jtreg, not useful for standalone execution as you have seen that one can get the problem running on freshly installed windows system. Making it manual will overcome standalone execution problem too.

It is similar to run the headful tests on windows/macOS w/o system preparation or run the tests on Linux w/o Xserver. Or similar to running the tests when the system shortcuts are enabled, will you change all tests which press combinations of keys to the manual tests? I assume no since these are the requirements for the tests run.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 06:53:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 06:53:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <QtrPXaaIbMwwdDLNStKJlbQWoZC01Sis0Sxmk8h-plc=.d9ef4240-1eb7-4a49-ad19-00d197b64aa7@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
 <-up-8GvJbTW2SvsqRuaN8u3lowBfbvxnfAPMdfINDBE=.3e6c4a14-a563-4f9f-a460-693cfbc19317@github.com>
 <iPVjSL9JFFydXE3NBHgQq3jiMpZ1rhPZKEYB2G74jso=.e2e4c94a-d15d-4258-9c8d-9f078eb08a0b@github.com>
 <MeDghiRAR1ltL6XPZ42yo-D-_sDu_U7URPKy0UFE5ms=.753a74bd-6dc3-4c75-86f5-4e52dbad5383@github.com>
 <LuKHXRnvXn723lNKXlajMNbolytBNu_FSaBgax-0zXg=.62b430d3-4339-4794-83d0-e0cba20aa697@github.com>
 <0G7k8bzAbfBeBX2PHWXDuSXBM0kk7tX6fT-nrMNiP0U=.a7cc5830-60a7-488f-9589-aac07c543473@github.com>
 <UbK8pbOwobr_pVhGGhP5zcHIkQK4bAkyV2kyphJDgFM=.4a2c5db4-ba1a-4499-bde6-8dffd9473e98@github.com>
 <3CgjxbTmr6kB2b1QV0iRbgYVjp7hlX0Gou2_BYRTths=.2c94ea40-87de-434a-b3af-b3f7dd102ad3@github.com>
 <QtrPXaaIbMwwdDLNStKJlbQWoZC01Sis0Sxmk8h-plc=.d9ef4240-1eb7-4a49-ad19-00d197b64aa7@github.com>
Message-ID: <hIHSq48w9HgEzN5KoM35VK_z7yGKCCH9E-ECUld6lw0=.9419a1ca-b552-46dc-bc6b-6f1534943cb9@github.com>

On Wed, 13 Jan 2021 06:28:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> OK. But it's a keyword for jtreg, not useful for standalone execution as you have seen that one can get the problem running on freshly installed windows system. Making it manual will overcome standalone execution problem too.
>
> It is similar to run the headful tests on windows/macOS w/o system preparation or run the tests on Linux w/o Xserver. Or similar to running the tests when the system shortcuts are enabled, will you change all tests which press combinations of keys to the manual tests? I assume no since these are the requirements for the tests run.

Ok. I will close this as not-an-issue then.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 06:58:59 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 06:58:59 GMT
Subject: [OpenJDK 2D-Dev] Withdrawn: 8215537: [TEST_BUG]
 java/awt/print/PrinterJob/LandscapeStackOverflow.java fails by timeout
In-Reply-To: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
References: <g0DeoxygLtaG6CUkfAOjSyJIGPTP23o7DFXc9D1G-fY=.7e284b3b-c536-4759-a27c-0bb02fe7c461@github.com>
Message-ID: <WaNFaq_MnyI_7A3wnxA3LISJzZgg9OELocdtJmRGhwQ=.d14c9b07-8bd8-431d-9949-18d37771b5b8@github.com>

On Mon, 4 Jan 2021 08:15:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test fails with timeout and it seems likely due to non-availability of printer in the test system. We should just update the test to check for default (or available) printers and return if there is no printer.

This pull request has been closed without being integrated.

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

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

From serb at openjdk.java.net  Wed Jan 13 07:07:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 13 Jan 2021 07:07:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259522: Apply java.io.Serial annotations
 in java.desktop [v2]
In-Reply-To: <0BeCSRlVfit-78buTvO8-tci6rZDhwsML4JXKzujLM8=.ff5ba622-5c99-4925-b690-5b348d0d0e18@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
 <0BeCSRlVfit-78buTvO8-tci6rZDhwsML4JXKzujLM8=.ff5ba622-5c99-4925-b690-5b348d0d0e18@github.com>
Message-ID: <ovc9uQxs9Nsvg5htYdyziTomnyod4crBGjDNjpBwiUk=.24dc5383-bb0c-4013-a049-8226fc1e81b7@github.com>

On Wed, 13 Jan 2021 06:10:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Why do we add serialVersionUID in some classes like DefaultMutableTreeNode.java but not in other swing classes?

Most Swing classes are marked by the specific "Warning" that "Same-version serialization only" is supported. (I think such a warning is missed in a few classes). So generally the serialVersionUID field is not needed in such classes, but if present this provides a small benefit -> this UID is not generated at runtime.

For example, the DefaultMutableTreeNode was updated by the JDK-5017904 fix, which was unrelated to serialization but was targeted for the performance issue.

> Also, if this change is for stricter compile-time checking, shouldn't we remove @SuppressWarnings("serial") check?

At some point, we probably can remove it but will need to fix all serialization warnings which were disabled.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 13 07:34:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 13 Jan 2021 07:34:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259522: Apply java.io.Serial annotations
 in java.desktop [v2]
In-Reply-To: <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
 <7X46pwNuTDGbEN3-jFa2QY2qUtMCK2dAu-BiPdoMK14=.19bc926b-62ba-4f79-8f32-be27898077a8@github.com>
Message-ID: <o6X-8cvIt6irtlI8WJGGl7ihtAzO2dau_KSDayRdh2Q=.36788283-5a33-4e4f-97f5-890d36d18359@github.com>

On Tue, 12 Jan 2021 20:42:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
>> 
>> This annotation can be applied to these methods in the module:
>> 
>>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>>     private void readObjectNoData() throws ObjectStreamException
>>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>>     private static final ObjectStreamField[] serialPersistentFields
>>     private static final long serialVersionUID
>> 
>> Notes:
>>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
>> 
>> A similar fix was implemented for java.base module as well:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html
>
> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
>    
>    Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

Marked as reviewed by psadhukhan (Reviewer).

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

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

From lbourges at openjdk.java.net  Thu Jan 14 09:32:13 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 14 Jan 2021 09:32:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision)
Message-ID: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>

- Removed MarlinRenderingEngine and related classes
- Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
- Marlin Version set to 0.9.1.4

Jtreg tests [test/jdk/sun/java2d/marlin/] : OK

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

Commit messages:
 - restored MarlinTileGenerator
 - JDK-8259681: removed MarlinRenderingEngine and related classes

Changes: https://git.openjdk.java.net/jdk/pull/2076/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2076&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259681
  Stats: 8573 lines in 15 files changed: 0 ins; 8566 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2076/head:pull/2076

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

From lbourges at openjdk.java.net  Thu Jan 14 11:17:19 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 14 Jan 2021 11:17:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v2]
In-Reply-To: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
Message-ID: <Em8SNWIRffvZDwGeTUxDFunYkcdIvfFIqeIiurZvluo=.6f39e034-7ed1-4993-b3e0-656db5e658bb@github.com>

> - Removed MarlinRenderingEngine and related classes
> - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
> - Marlin Version set to 0.9.1.4
> 
> Jtreg tests [test/jdk/sun/java2d/marlin/] : OK

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  fixed invalid Stroker.CAP_BUTT reference

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2076/files
  - new: https://git.openjdk.java.net/jdk/pull/2076/files/806a9053..14660d92

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

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

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

From lbourges at openjdk.java.net  Thu Jan 14 12:30:02 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 14 Jan 2021 12:30:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision)
In-Reply-To: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
Message-ID: <DNnO6G6-gcJMO0C9T1b0mjJ72q6bRAGtH7sQs4I6NTs=.ce6e792b-26ff-404b-8994-36e9963faa32@github.com>

On Thu, 14 Jan 2021 09:27:41 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> - Removed MarlinRenderingEngine and related classes
> - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
> - Marlin Version set to 0.9.1.4
> 
> Jtreg tests [test/jdk/sun/java2d/marlin/] : OK

Apparently windows x64 build failed: no C compiler found !

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

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

From prr at openjdk.java.net  Thu Jan 14 15:54:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 14 Jan 2021 15:54:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision)
In-Reply-To: <DNnO6G6-gcJMO0C9T1b0mjJ72q6bRAGtH7sQs4I6NTs=.ce6e792b-26ff-404b-8994-36e9963faa32@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <DNnO6G6-gcJMO0C9T1b0mjJ72q6bRAGtH7sQs4I6NTs=.ce6e792b-26ff-404b-8994-36e9963faa32@github.com>
Message-ID: <4UabF7e4tSIk5Rze97Ah189ExAbpAKQeyj54J3llzbE=.7cbd4a77-ba1f-4bcb-946d-04a630624a25@github.com>

On Thu, 14 Jan 2021 12:26:48 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> Apparently windows x64 build failed: no C compiler found !

Other PRs have the same issue. I suppose problem with github actions. Maybe the github default compiler change.

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

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

From brett.okken.os at gmail.com  Thu Jan 14 17:09:16 2021
From: brett.okken.os at gmail.com (Brett Okken)
Date: Thu, 14 Jan 2021 11:09:16 -0600
Subject: [OpenJDK 2D-Dev] Using VarHandle to read/write primitives
Message-ID: <CANBJVOE9mvyuhBunT-6ntrS7AqhbLQponpO5y15M+krXu+6AJw@mail.gmail.com>

In ImageInputStreamImpl and ImageOutputStreamImpl there are methods to
read and write other primitive and primitive array types.

Has there been thought of using byte array view VarHandles[1] to
implement these actions rather than bit twiddling?

[1] - https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/MethodHandles.html#byteArrayViewVarHandle(java.lang.Class,java.nio.ByteOrder)

From serb at openjdk.java.net  Fri Jan 15 00:31:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Jan 2021 00:31:01 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8259522: Apply java.io.Serial
 annotations in java.desktop
In-Reply-To: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
References: <ldbt1O3HzPJ_QcyXHWuLT5ApDbVZf1XMqkhNr9bTz38=.9b80cb2b-c20f-4664-9684-2bf64c55e643@github.com>
Message-ID: <G3x8Wr0SIEUSodquvRdnsV88amw32tPuXweX4QBcSXU=.f7d4d3fd-d9c1-4092-b223-49bc919e980d@github.com>

On Mon, 11 Jan 2021 06:21:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of @java.io.Serial annotation (JDK-8202385) to types in the desktop module to enable stricter compile-time checking of serialization-related declarations.
> 
> This annotation can be applied to these methods in the module:
> 
>     private void writeObject(java.io.ObjectOutputStream stream) throws IOException
>     private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
>     private void readObjectNoData() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
>     ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
>     private static final ObjectStreamField[] serialPersistentFields
>     private static final long serialVersionUID
> 
> Notes:
>   - I have tried to update the comments for serialVersionUID as accurately as possible, but mostly based on the source code history and bugs in JBS where that field was added
>   - Some of the readObject/writeObject methods in the javax.swing package does not have a spec, because this package and some others are excluded from the serialization specification.
> 
> A similar fix was implemented for java.base module as well:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062046.html

This pull request has now been integrated.

Changeset: 978bed6c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/978bed6c
Stats:     3424 lines in 343 files changed: 2264 ins; 287 del; 873 mod

8259522: Apply java.io.Serial annotations in java.desktop

Reviewed-by: aivanov, psadhukhan

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

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

From serb at openjdk.java.net  Fri Jan 15 01:25:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Jan 2021 01:25:05 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision)
In-Reply-To: <4UabF7e4tSIk5Rze97Ah189ExAbpAKQeyj54J3llzbE=.7cbd4a77-ba1f-4bcb-946d-04a630624a25@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <DNnO6G6-gcJMO0C9T1b0mjJ72q6bRAGtH7sQs4I6NTs=.ce6e792b-26ff-404b-8994-36e9963faa32@github.com>
 <4UabF7e4tSIk5Rze97Ah189ExAbpAKQeyj54J3llzbE=.7cbd4a77-ba1f-4bcb-946d-04a630624a25@github.com>
Message-ID: <ZEXjv9LDDUPRZyTkz8-EEowoDspMpKsvQFnyt2bq8dE=.f04d200d-e9be-4877-8a72-8668d33ee89e@github.com>

On Thu, 14 Jan 2021 15:51:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> Apparently windows x64 build failed: no C compiler found !
>
>> Apparently windows x64 build failed: no C compiler found !
> 
> Other PRs have the same issue. I suppose problem with github actions. Maybe the github default compiler change.

I'll start internal testing.

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

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

From serb at openjdk.java.net  Fri Jan 15 02:10:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Jan 2021 02:10:05 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision)
In-Reply-To: <ZEXjv9LDDUPRZyTkz8-EEowoDspMpKsvQFnyt2bq8dE=.f04d200d-e9be-4877-8a72-8668d33ee89e@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <DNnO6G6-gcJMO0C9T1b0mjJ72q6bRAGtH7sQs4I6NTs=.ce6e792b-26ff-404b-8994-36e9963faa32@github.com>
 <4UabF7e4tSIk5Rze97Ah189ExAbpAKQeyj54J3llzbE=.7cbd4a77-ba1f-4bcb-946d-04a630624a25@github.com>
 <ZEXjv9LDDUPRZyTkz8-EEowoDspMpKsvQFnyt2bq8dE=.f04d200d-e9be-4877-8a72-8668d33ee89e@github.com>
Message-ID: <b9gnjheNhdq1YVY0y82ybOZjWaorjro_h4OE-faZFGs=.4aa2007c-dc1a-4642-a296-3ded8915ef30@github.com>

On Fri, 15 Jan 2021 01:22:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Apparently windows x64 build failed: no C compiler found !
>> 
>> Other PRs have the same issue. I suppose problem with github actions. Maybe the github default compiler change.
>
> I'll start internal testing.

please update the copyright dates

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

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

From serb at openjdk.java.net  Fri Jan 15 07:42:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Jan 2021 07:42:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v2]
In-Reply-To: <Em8SNWIRffvZDwGeTUxDFunYkcdIvfFIqeIiurZvluo=.6f39e034-7ed1-4993-b3e0-656db5e658bb@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <Em8SNWIRffvZDwGeTUxDFunYkcdIvfFIqeIiurZvluo=.6f39e034-7ed1-4993-b3e0-656db5e658bb@github.com>
Message-ID: <9jqbpcFf4ut9CIng69PDqoEe6MJRIyj3voITYtFlo-g=.74044c6b-5f50-4a12-9301-9de8c55a5e8c@github.com>

On Thu, 14 Jan 2021 11:17:19 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> - Removed MarlinRenderingEngine and related classes
>> - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
>> - Marlin Version set to 0.9.1.4
>> 
>> Jtreg tests [test/jdk/sun/java2d/marlin/] : OK
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed invalid Stroker.CAP_BUTT reference

Marked as reviewed by serb (Reviewer).

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

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

From linuxhippy at gmail.com  Fri Jan 15 08:32:58 2021
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 15 Jan 2021 09:32:58 +0100
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work concurrently
 with AWT threads possible? (... the future of the opengl pipeline)
Message-ID: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>

Hi,

With solid OpenGL support on Linux being ubiquitous these days and the
XRender pipeline being a bit of a dead-end (works quite well except
MaskBlit/MaskFill/BufferedImageOps), I was looking a bit into the
state/performance of the OpenGL pipeline.
Specifically why it performs sometimes worse compared to XRender, despite
almost all XRender implementations are running on top of OpenGL these days
anyway (except proprietary nvidia).

1. One area where XRender is having an advantage is implicit parallelism.
While Java is producing X11 protocol, the XServer can concurrently perform
the drawing operations running on a different core.
Therefore when running some Swing benchmarks with xrender enabled I see
java consuming 100% of one core, while the XServer consumes ~50% of another
one.
With the OpenGL pipeline on the other hand, just one core is fully loaded -
despite a similar design (one flusher thread calling into OpenGL, and one
or more independent threads queuing drawing operations into a buffer).

The reason seems to be the OGLRenderQueue has just one buffer, so either
the flusher thread is active or a queuing thread but not both.
I wonder, have there been attempts made to introduce double-buffering here
and have producers (awt threads) and consumer (queue flusher thread)
running concurrently here?

2. Especially MaskFill did perform quite poor in my tests, because drivers
are typically not optimized for tiny texture uploads (32x32 coverage masks).
Just stubbing out the subTex2D call improved framerate of one benchmark
from 100fps to 300fps.
I have done some prototyping uploading coverage masks via
Shader_Storage_Buffer_Object, but that requires
ARB_shader_storage_buffer_object (GL 4.3) as well glBufferStorage (4.4), so
effectivly OpenGL-4.4.
On the pro side of this approach composition peaked at about 10GB/s with
64x64 mask tiles.

Which leads me to the next question:
The pipeline currently is written in rather ancient OpenGL-2.x style.
Once the need to support old OSX versions is gone, the OpenGL pipeline
would not be enabled be default on any platform.
Once this is the case, would it be feasable to clean up the code by making
use of modern GL and by leaving legacy platforms behind?
Modern GL has many improvements in areas where the current pipeline is
suffering a bit (overhead of state changes for small drawing operations,
etc).

Thanks and best regards, Clemens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210115/e2c3266e/attachment.htm>

From bourges.laurent at gmail.com  Fri Jan 15 11:06:25 2021
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 15 Jan 2021 12:06:25 +0100
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work
 concurrently with AWT threads possible? (... the future of the opengl
 pipeline)
In-Reply-To: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
References: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
Message-ID: <CAKjRUT7cVhEaH+UzuyWhppx8QnGWh9s7NAVhsuFwEuwjORyGww@mail.gmail.com>

Hi Clemens,

It reminds me our discussion few years ago, when I experimented opengl on
linux and tuned the OGLRenderQueue for the Marlin renderer, see:
-
https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/pipe/RenderQueue.java
-
https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/opengl/OGLRenderQueue.java

1. These changes mainly consists in increasing internal queue buffer from
32K to 1 Mb (based on my own performance tests).
Ideally an heuristic (data volume per second) could help estimating the
appropriate queue capacity needed to automatically optimize the producer
writing / consumer reading speed.

I like your idea to have multiple queue producer but a single consumer
means a single Surface destination at 1 time ?
How to do parallel rendering on different surfaces (ogl context switch) ?

2. As the Marlin renderer supports large tiles (up to 256x256), it is very
easy to adjust Marlin tiles at runtime for performance:
-Dsun.java2d.renderer.log=true
-Dsun.java2d.renderer.tileSize_log2=5
-Dsun.java2d.renderer.tileWidth_log2=5

By default, 5 means 2^5 = 32.
Just set larger values: -Dsun.java2d.renderer.tileSize_log2=6
-Dsun.java2d.renderer.tileWidth_log2=6

Finally your proposal is amazing and I could join you in your efforts, if
we publicly work on the same repository (github.com ?)

Cheers,
Happy New Year,

Laurent


Le ven. 15 janv. 2021 ? 09:35, Clemens Eisserer <linuxhippy at gmail.com> a
?crit :

> Hi,
>
> With solid OpenGL support on Linux being ubiquitous these days and the
> XRender pipeline being a bit of a dead-end (works quite well except
> MaskBlit/MaskFill/BufferedImageOps), I was looking a bit into the
> state/performance of the OpenGL pipeline.
> Specifically why it performs sometimes worse compared to XRender, despite
> almost all XRender implementations are running on top of OpenGL these days
> anyway (except proprietary nvidia).
>
> 1. One area where XRender is having an advantage is implicit parallelism.
> While Java is producing X11 protocol, the XServer can concurrently perform
> the drawing operations running on a different core.
> Therefore when running some Swing benchmarks with xrender enabled I see
> java consuming 100% of one core, while the XServer consumes ~50% of another
> one.
> With the OpenGL pipeline on the other hand, just one core is fully loaded
> - despite a similar design (one flusher thread calling into OpenGL, and one
> or more independent threads queuing drawing operations into a buffer).
>
> The reason seems to be the OGLRenderQueue has just one buffer, so either
> the flusher thread is active or a queuing thread but not both.
> I wonder, have there been attempts made to introduce double-buffering here
> and have producers (awt threads) and consumer (queue flusher thread)
> running concurrently here?
>
> 2. Especially MaskFill did perform quite poor in my tests, because drivers
> are typically not optimized for tiny texture uploads (32x32 coverage masks).
> Just stubbing out the subTex2D call improved framerate of one benchmark
> from 100fps to 300fps.
> I have done some prototyping uploading coverage masks via
> Shader_Storage_Buffer_Object, but that requires
> ARB_shader_storage_buffer_object (GL 4.3) as well glBufferStorage (4.4), so
> effectivly OpenGL-4.4.
> On the pro side of this approach composition peaked at about 10GB/s with
> 64x64 mask tiles.
>
> Which leads me to the next question:
> The pipeline currently is written in rather ancient OpenGL-2.x style.
> Once the need to support old OSX versions is gone, the OpenGL pipeline
> would not be enabled be default on any platform.
> Once this is the case, would it be feasable to clean up the code by making
> use of modern GL and by leaving legacy platforms behind?
> Modern GL has many improvements in areas where the current pipeline is
> suffering a bit (overhead of state changes for small drawing operations,
> etc).
>
> Thanks and best regards, Clemens
>


-- 
-- 
Laurent Bourg?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210115/5ba3ec9d/attachment-0001.htm>

From lbourges at openjdk.java.net  Fri Jan 15 11:19:19 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 15 Jan 2021 11:19:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v3]
In-Reply-To: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
Message-ID: <uvbngQwytIuyRB5YVoWU226Iu8-WR_9btUkCsaqGWJ4=.a8f56105-10c6-491d-9b1f-038b02f4be2a@github.com>

> - Removed MarlinRenderingEngine and related classes
> - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
> - Marlin Version set to 0.9.1.4
> 
> Jtreg tests [test/jdk/sun/java2d/marlin/] : OK

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  fixed copyright year + removed useless interfaces (IRendererContext, MarlinRenderer)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2076/files
  - new: https://git.openjdk.java.net/jdk/pull/2076/files/14660d92..ebcd0cd3

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

  Stats: 88 lines in 7 files changed: 0 ins; 75 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2076/head:pull/2076

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

From lbourges at openjdk.java.net  Fri Jan 15 11:31:05 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 15 Jan 2021 11:31:05 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v2]
In-Reply-To: <9jqbpcFf4ut9CIng69PDqoEe6MJRIyj3voITYtFlo-g=.74044c6b-5f50-4a12-9301-9de8c55a5e8c@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <Em8SNWIRffvZDwGeTUxDFunYkcdIvfFIqeIiurZvluo=.6f39e034-7ed1-4993-b3e0-656db5e658bb@github.com>
 <9jqbpcFf4ut9CIng69PDqoEe6MJRIyj3voITYtFlo-g=.74044c6b-5f50-4a12-9301-9de8c55a5e8c@github.com>
Message-ID: <l70iaqQt7OxvDSTggBEJrzZ2VI5rL2KFFSBdv-ktByc=.6cee3af2-27e8-4470-a364-18beb32cd4c9@github.com>

On Fri, 15 Jan 2021 07:38:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed invalid Stroker.CAP_BUTT reference
>
> Marked as reviewed by serb (Reviewer).

Sergey, I slightly modified the reviewed change:
see incremental changes: https://openjdk.github.io/cr/?repo=jdk&pr=2076&range=01-02

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

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

From lbourges at openjdk.java.net  Fri Jan 15 11:37:01 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 15 Jan 2021 11:37:01 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v2]
In-Reply-To: <l70iaqQt7OxvDSTggBEJrzZ2VI5rL2KFFSBdv-ktByc=.6cee3af2-27e8-4470-a364-18beb32cd4c9@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <Em8SNWIRffvZDwGeTUxDFunYkcdIvfFIqeIiurZvluo=.6f39e034-7ed1-4993-b3e0-656db5e658bb@github.com>
 <9jqbpcFf4ut9CIng69PDqoEe6MJRIyj3voITYtFlo-g=.74044c6b-5f50-4a12-9301-9de8c55a5e8c@github.com>
 <l70iaqQt7OxvDSTggBEJrzZ2VI5rL2KFFSBdv-ktByc=.6cee3af2-27e8-4470-a364-18beb32cd4c9@github.com>
Message-ID: <oOz8C0pQGUSJDeuLZqSBVFljc6cd4qH0U4pAlKVxiGw=.3cbf4185-9500-447b-9185-ed5c787846ff@github.com>

On Fri, 15 Jan 2021 11:28:35 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> Marked as reviewed by serb (Reviewer).
>
> Sergey, I slightly modified the reviewed change:
> see incremental changes: https://openjdk.github.io/cr/?repo=jdk&pr=2076&range=01-02

One more idea: 
should I rename all Dxxx classes to xxx to make code more obvious, readable ?

However, renaming DMarlinRenderingEngine to MarlinRenderingEngine may lead confusion with previous versions and may be a compatibility issue ? so I would prefer keeping DMarlinRenderingEngine now.

What do you think ?

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

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

From alanb at openjdk.java.net  Fri Jan 15 15:01:09 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Jan 2021 15:01:09 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module [v4]
In-Reply-To: <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
Message-ID: <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>

On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Marked as reviewed by prr (Reviewer).
>
> This PR is not stale; it's just still waiting for input from @AlanBateman.

@magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang?

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

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

From mark.reinhold at oracle.com  Fri Jan 15 18:27:09 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 15 Jan 2021 10:27:09 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module
In-Reply-To: <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
Message-ID: <20210115102709.538599954@eggemoggin.niobe.net>

2020/12/4 6:08:13 -0800, erikj at openjdk.java.net:
> On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>>> And I can certainly move jdwp.spec to java.base instead. That's the
>>> reason I need input on this: All I know is that is definitely not
>>> the responsibility of the Build Group to maintain that document, and
>>> I made my best guess at where to place it.
>> 
>>> And I can certainly move jdwp.spec to java.base instead.
>> 
>> If jdwp.spec has to move to the src tree then src/java.se is probably
>> the most suitable home because Java SE specifies JDWP as an optional
>> interface. So nothing to do with java.base and the build will need to
>> continue to generate the sources for the front-end (jdk.jdi) and
>> back-end (jdk.jdwp.agent) as they implement the protocol.
> 
> My understanding of JEPs is that they should be viewed as living
> documents. In this case, I think it's perfectly valid to update JEP
> 201 with additional source code layout. Both for this and for the
> other missing dirs.

Feature JEPs are living documents until such time as they are delivered.
In this case it would not be appropriate to update JEP 201, which is as
much about the transition from the old source-code layout as it is about
the new layout as of 2014.

At this point, and given that we?d already gone beyond JEP 201 prior to
this change (with `man` and `lib` subdirectories), what?d make the most
sense is a new informational JEP that documents the source-code layout.
Informational JEPs can, within reason, be updated over time.

- Mark

From ihse at openjdk.java.net  Fri Jan 15 18:30:07 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 15 Jan 2021 18:30:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module [v4]
In-Reply-To: <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
 <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
Message-ID: <mPNUm7AkV0tIzHSYB15g2W4pJpA_F3xYeZUoyEqmrB0=.3a8bfe9e-9f23-4bad-94bc-fd4d4d599f25@github.com>

On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang?

@AlanBateman That sounds like an excellent idea. I'll update the PR first thing next week. :)

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

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

From serb at openjdk.java.net  Fri Jan 15 23:09:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 15 Jan 2021 23:09:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v2]
In-Reply-To: <oOz8C0pQGUSJDeuLZqSBVFljc6cd4qH0U4pAlKVxiGw=.3cbf4185-9500-447b-9185-ed5c787846ff@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <Em8SNWIRffvZDwGeTUxDFunYkcdIvfFIqeIiurZvluo=.6f39e034-7ed1-4993-b3e0-656db5e658bb@github.com>
 <9jqbpcFf4ut9CIng69PDqoEe6MJRIyj3voITYtFlo-g=.74044c6b-5f50-4a12-9301-9de8c55a5e8c@github.com>
 <l70iaqQt7OxvDSTggBEJrzZ2VI5rL2KFFSBdv-ktByc=.6cee3af2-27e8-4470-a364-18beb32cd4c9@github.com>
 <oOz8C0pQGUSJDeuLZqSBVFljc6cd4qH0U4pAlKVxiGw=.3cbf4185-9500-447b-9185-ed5c787846ff@github.com>
Message-ID: <IHlFyWc_koENlgx9XCD-04cAKHHanTI_mUFWFBpgMlU=.c6eef654-e45d-4869-9ad1-84e9160f65f0@github.com>

On Fri, 15 Jan 2021 11:34:35 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> However, renaming DMarlinRenderingEngine to MarlinRenderingEngine may lead confusion with previous versions and may be a compatibility issue ? so I would prefer keeping DMarlinRenderingEngine now.

I agree with you.

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

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

From Sergey.Bylokhov at oracle.com  Fri Jan 15 23:38:01 2021
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Jan 2021 15:38:01 -0800
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work
 concurrently with AWT threads possible? (... the future of the opengl
 pipeline)
In-Reply-To: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
References: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
Message-ID: <b8f4d582-59c2-83d5-f723-a52e64d8004b@oracle.com>

On 15.01.2021 00:32, Clemens Eisserer wrote:
> With solid OpenGL support on Linux being ubiquitous these days and the XRender pipeline being a bit of a dead-end (works quite well except MaskBlit/MaskFill/BufferedImageOps), I was looking a bit into the state/performance of the OpenGL pipeline.
> Specifically why it performs sometimes worse compared to XRender, despite almost all XRender implementations are running on top of OpenGL these days anyway (except proprietary nvidia).
> 
> 1. One area where XRender is having an advantage is implicit parallelism.
> While Java is producing X11 protocol, the XServer can concurrently perform the drawing operations running on a different core.
> Therefore when running some Swing benchmarks with xrender enabled I see java consuming 100% of one core, while the XServer consumes ~50% of another one.
> With the OpenGL pipeline on the other hand, just one core is fully loaded - despite a similar design (one flusher thread calling into OpenGL, and one or more independent threads queuing drawing operations into a buffer).

The design is a little bit different, the XRender pipeline:
  - Many threads which call draw operations and sends them to the XServer
  - The XSerever decode the the draw operation and push the commands to the "opengl buffer"
  - Some video driver code which decode the ogl buffer and actually draw something
The OGL pipeline
  - Many threads call draw operations, and save them in the internal RenderQueue buffer
  - One RenderQueue thread decode the the draw operation and push the commands to the "opengl buffer"
  - Some video driver code which decode the ogl buffer and actually draw something

Depends on the method on how to measure the performance results will be different.
  - For the screen rendering you will need to check the screen, is something is really rendering(glflush and XFlush could help a little bit but not always)
  - For the volatile image you will need to test roundtrip when you write and read data

The only obviously bad results could occur if some pipeline will use the software rendering(even for some small intermittent operations)

> The reason seems to be the OGLRenderQueue has just one buffer, so either the flusher thread is active or a queuing thread but not both.
> I wonder, have there been attempts made to introduce double-buffering here and have producers (awt threads) and consumer (queue flusher thread) running concurrently here?

I am not sure that it work that way, the only way to block the queuing thread is to call "flushNow()", for other cases it should not be blocked.
The OGLRenderQueue thread however could became blocked every 100ms.

> 
> 2. Especially MaskFill did perform quite poor in my tests, because drivers are typically not optimized for tiny texture uploads (32x32 coverage masks).
> Just stubbing out the subTex2D call improved framerate of one benchmark from 100fps to 300fps.
> I have done some prototyping uploading coverage masks via Shader_Storage_Buffer_Object, but that requires? ARB_shader_storage_buffer_object (GL 4.3) as well glBufferStorage (4.4), so effectivly OpenGL-4.4.
> On the pro side of this approach composition peaked at about 10GB/s with 64x64 mask tiles.

There are many ways to improve the OGL pipeline using new OGL feature, but be aware that currently the OGL
pipeline is the only one crossplatform pipeline which works virtually on most of devices(new and old).
A similar architecture issue exists in the d3d pipeline as well, so maybe the Vulkan will better,
it could replace XRender and D3D someday?

I thought Vulkan superseded the OGL, no?

> 
> Which leads me to the next question:
> The pipeline currently is written in rather ancient OpenGL-2.x style.
> Once the need to support old OSX versions is gone, the OpenGL pipeline would not be enabled be default on any platform.
> Once this is the case, would it be feasable to clean up the code by making use of modern GL and by leaving legacy platforms behind?
> Modern GL has many improvements in areas where the current pipeline is suffering a bit (overhead of state changes for small drawing operations, etc).


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Jan 15 23:50:16 2021
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 15 Jan 2021 15:50:16 -0800
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work
 concurrently with AWT threads possible? (... the future of the opengl
 pipeline)
In-Reply-To: <CAKjRUT7cVhEaH+UzuyWhppx8QnGWh9s7NAVhsuFwEuwjORyGww@mail.gmail.com>
References: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
 <CAKjRUT7cVhEaH+UzuyWhppx8QnGWh9s7NAVhsuFwEuwjORyGww@mail.gmail.com>
Message-ID: <2ca5c098-bc55-4e25-b517-38cc3108161f@oracle.com>

On 15.01.2021 03:06, Laurent Bourg?s wrote:
> Hi Clemens,
> 
> It reminds me our discussion few years ago, when I experimented opengl on linux and tuned the OGLRenderQueue for the Marlin renderer, see:
> - https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/pipe/RenderQueue.java <https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/pipe/RenderQueue.java>
> - https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/opengl/OGLRenderQueue.java <https://github.com/bourgesl/marlin-renderer/blob/jdk/src/main/java/sun/java2d/opengl/OGLRenderQueue.java>
> 
> 1. These changes mainly consists in increasing internal queue buffer from 32K to 1 Mb (based on my own performance tests).
> Ideally an heuristic (data volume per second) could help estimating the appropriate queue capacity needed to automatically optimize the producer writing / consumer reading speed.

The problem with increasing the buffer is that it can cause unexpected spikes during drawing -> Most of the draw operations will work faster because all of them just put the "draw operation" to the buffer and the flush will occur less often, but the flush operation itself will be slower. Imagine a situation when the user draws something on the screen while the 1 Mb buffer is full.
Also note that executing OGL commands in native on the OGLRenderQueue does not mean that the picture is rendered on the screen, it could be possible that the picture will appeared at the end of the buffer when will call glFlush/glFinish, so the lag could occurred when we flush 1Mb vs 32k.


-- 
Best regards, Sergey.

From serb at openjdk.java.net  Sat Jan 16 07:33:24 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 16 Jan 2021 07:33:24 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException [v4]
In-Reply-To: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
Message-ID: <zYzFfOhgeKMnE2EgrWPwqx0296_K4at3rxwK0lPbaG0=.eca07b97-3f6d-48da-a085-5af676f84835@github.com>

> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
> 
> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
> 
> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
> 
> Notes about the link above:
> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
> 
> The fix:
>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
> 
> See some comments inline.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into JDK-6986863
 - Update ProfileActivationDuringPropertyAccess.java
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Delete the DeferralMgr machinery
 - Update ICC_Profile.java
 - Wrong spec in ProfileDeferralInfo
 - Update ICC_Profile.java
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d63388c0...884f9e90

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

Changes: https://git.openjdk.java.net/jdk/pull/1613/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1613&range=03
  Stats: 520 lines in 9 files changed: 183 ins; 265 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1613/head:pull/1613

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

From kcr at openjdk.java.net  Sat Jan 16 16:59:39 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 16 Jan 2021 16:59:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v2]
In-Reply-To: <IHlFyWc_koENlgx9XCD-04cAKHHanTI_mUFWFBpgMlU=.c6eef654-e45d-4869-9ad1-84e9160f65f0@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <Em8SNWIRffvZDwGeTUxDFunYkcdIvfFIqeIiurZvluo=.6f39e034-7ed1-4993-b3e0-656db5e658bb@github.com>
 <9jqbpcFf4ut9CIng69PDqoEe6MJRIyj3voITYtFlo-g=.74044c6b-5f50-4a12-9301-9de8c55a5e8c@github.com>
 <l70iaqQt7OxvDSTggBEJrzZ2VI5rL2KFFSBdv-ktByc=.6cee3af2-27e8-4470-a364-18beb32cd4c9@github.com>
 <oOz8C0pQGUSJDeuLZqSBVFljc6cd4qH0U4pAlKVxiGw=.3cbf4185-9500-447b-9185-ed5c787846ff@github.com>
 <IHlFyWc_koENlgx9XCD-04cAKHHanTI_mUFWFBpgMlU=.c6eef654-e45d-4869-9ad1-84e9160f65f0@github.com>
Message-ID: <r5awvoNYYfu0GVN_KtBj_ooujG2sKlc8LGln1YcxQSc=.ad7c8ceb-3cce-4849-a6b2-18c74170ca79@github.com>

On Fri, 15 Jan 2021 23:06:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> One more idea: 
>> should I rename all Dxxx classes to xxx to make code more obvious, readable ?
>> 
>> However, renaming DMarlinRenderingEngine to MarlinRenderingEngine may lead confusion with previous versions and may be a compatibility issue ? so I would prefer keeping DMarlinRenderingEngine now.
>> 
>> What do you think ?
>
>> However, renaming DMarlinRenderingEngine to MarlinRenderingEngine may lead confusion with previous versions and may be a compatibility issue ? so I would prefer keeping DMarlinRenderingEngine now.
> 
> I agree with you.

I also agree with this. Similarly, when you go to remove the single-precision `MarlinRasterizer` from JavaFX, via [JDK-8259718](https://bugs.openjdk.java.net/browse/JDK-8259718), I would expect to see `DMarlinRasterizer` and similar names to remain.

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

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

From serb at openjdk.java.net  Sat Jan 16 21:41:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 16 Jan 2021 21:41:29 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v3]
In-Reply-To: <uvbngQwytIuyRB5YVoWU226Iu8-WR_9btUkCsaqGWJ4=.a8f56105-10c6-491d-9b1f-038b02f4be2a@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <uvbngQwytIuyRB5YVoWU226Iu8-WR_9btUkCsaqGWJ4=.a8f56105-10c6-491d-9b1f-038b02f4be2a@github.com>
Message-ID: <y8PQMZjJ_9kPV4wF_rspd0pQdUO5TltLKigaQ8wRXQk=.687f2700-48c3-4f8d-a05b-659d363afc22@github.com>

On Fri, 15 Jan 2021 11:19:19 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> - Removed MarlinRenderingEngine and related classes
>> - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
>> - Marlin Version set to 0.9.1.4
>> 
>> Jtreg tests [test/jdk/sun/java2d/marlin/] : OK
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed copyright year + removed useless interfaces (IRendererContext, MarlinRenderer)

Marked as reviewed by serb (Reviewer).

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

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

From lbourges at openjdk.java.net  Sun Jan 17 09:07:37 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 17 Jan 2021 09:07:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v4]
In-Reply-To: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
Message-ID: <PffD7ZzNzxilauqCn5nPhw1gPsAGfE20BC-dCXU9h8U=.a4e89edd-1c89-496a-93f8-9725b5b65cd7@github.com>

> - Removed MarlinRenderingEngine and related classes
> - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
> - Marlin Version set to 0.9.1.4
> 
> Jtreg tests [test/jdk/sun/java2d/marlin/] : OK

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  renamed Dxx classes to their original names

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2076/files
  - new: https://git.openjdk.java.net/jdk/pull/2076/files/ebcd0cd3..80428a96

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

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

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

From lbourges at openjdk.java.net  Sun Jan 17 09:29:28 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 17 Jan 2021 09:29:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v3]
In-Reply-To: <y8PQMZjJ_9kPV4wF_rspd0pQdUO5TltLKigaQ8wRXQk=.687f2700-48c3-4f8d-a05b-659d363afc22@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <uvbngQwytIuyRB5YVoWU226Iu8-WR_9btUkCsaqGWJ4=.a8f56105-10c6-491d-9b1f-038b02f4be2a@github.com>
 <y8PQMZjJ_9kPV4wF_rspd0pQdUO5TltLKigaQ8wRXQk=.687f2700-48c3-4f8d-a05b-659d363afc22@github.com>
Message-ID: <26Z5Os95OOq_isTF3OJECTtc5IAb4zCbe_XvSxDP1CE=.ee883ab5-cfc1-4584-94c9-97eca310bd9a@github.com>

On Sat, 16 Jan 2021 21:38:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed copyright year + removed useless interfaces (IRendererContext, MarlinRenderer)
>
> Marked as reviewed by serb (Reviewer).

Sergey, I made the class refactoring, more clear in incremental webrev:
https://openjdk.github.io/cr/?repo=jdk&pr=2076&range=02-03
Still Approved ?

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

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

From lbourges at openjdk.java.net  Sun Jan 17 10:31:45 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 17 Jan 2021 10:31:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v3]
In-Reply-To: <26Z5Os95OOq_isTF3OJECTtc5IAb4zCbe_XvSxDP1CE=.ee883ab5-cfc1-4584-94c9-97eca310bd9a@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <uvbngQwytIuyRB5YVoWU226Iu8-WR_9btUkCsaqGWJ4=.a8f56105-10c6-491d-9b1f-038b02f4be2a@github.com>
 <y8PQMZjJ_9kPV4wF_rspd0pQdUO5TltLKigaQ8wRXQk=.687f2700-48c3-4f8d-a05b-659d363afc22@github.com>
 <26Z5Os95OOq_isTF3OJECTtc5IAb4zCbe_XvSxDP1CE=.ee883ab5-cfc1-4584-94c9-97eca310bd9a@github.com>
Message-ID: <EvGABglmouL0tCx63ghA7UEb71MY9M3TxifwgwuVYzs=.76a1bd5f-34de-43ee-9566-2399edd7480f@github.com>

On Sun, 17 Jan 2021 09:27:03 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> Marked as reviewed by serb (Reviewer).
>
> Sergey, I made the class refactoring, more clear in incremental webrev:
> https://openjdk.github.io/cr/?repo=jdk&pr=2076&range=02-03
> Still Approved ?

Forgot to fix copyright year on renamed classes, sorry

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

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

From linuxhippy at gmail.com  Sun Jan 17 12:08:36 2021
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sun, 17 Jan 2021 13:08:36 +0100
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work
 concurrently with AWT threads possible? (... the future of the opengl
 pipeline)
In-Reply-To: <b8f4d582-59c2-83d5-f723-a52e64d8004b@oracle.com>
References: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
 <b8f4d582-59c2-83d5-f723-a52e64d8004b@oracle.com>
Message-ID: <CAFvQSYSsYyvn0-3V8-A4ZSmvp2ChpKAfD=cnsYFW_vdHi8YHVw@mail.gmail.com>

Hi Sergey,

> The design is a little bit different, the XRender pipeline:
>   - Many threads which call draw operations and sends them to the XServer
>   - The XSerever decode the the draw operation and push the commands to
the "opengl buffer"
>   - Some video driver code which decode the ogl buffer and actually draw
something
> The OGL pipeline
>   - Many threads call draw operations, and save them in the internal
RenderQueue buffer
>   - One RenderQueue thread decode the the draw operation and push the
commands to the "opengl buffer"
>   - Some video driver code which decode the ogl buffer and actually draw
something

So in both cases producers (application threads) and the consumer are
decoupled via some kind of queue (unix domain socket for x11, in-memory
queue for the renderqueue) and in theory could operate concurrently.

> I am not sure that it work that way, the only way to block the queuing
thread is to call "flushNow()", for other cases it should not be blocked.
> The OGLRenderQueue thread however could became blocked every 100ms.

Since there is only one RenderQueue+Buffer, the entire queue has to be
locked while the commands are processed by the RenderQueue-Thread (via the
AWT lock held by the thread which is implicitly calling flushNow triggered
by a full buffer).
This serverly limits parallelism - you can either process commands
(RenderQueue thread) or queue new commands (AWT threads) but not both at
the same time.
This lead me to the original question - whether this was a necessity caused
by structural requirements/limitations or whether it simply hasn't been
thought through / implemented.

I did some prototyping of a double-buffered renderqueue (no other changes)
over the weekend and results are really promising (1x1 fillRect to measure
pipeline-overhead, 20x20 aa oval to get an impression data-heavy buffer
interaction):

Test(graphics.render.tests.fillRect) averaged 1.4837645794468326E7
pixels/sec
   with !antialias, to VolatileImg(), ident, SrcOver, single, width1, 1x1,
!clip, bounce, Default, !xormode, !alphacolor, !extraalpha
Test(graphics.render.tests.fillOval) averaged 3.896264839428713E7 pixels/sec
   with !alphacolor, SrcOver, 20x20, Default, antialias, bounce, !xormode,
to VolatileImg(), !clip, width1, !extraalpha, single, ident

whereas the original JDK with OGL yielded:

Test(graphics.render.tests.fillRect) averaged 5061909.644344761 pixels/sec
   with single, 1x1, SrcOver, !extraalpha, bounce, Default, !xormode, to
VolatileImg(), ident, !alphacolor, width1, !antialias, !clip
Test(graphics.render.tests.fillOval) averaged 1.0837940280832347E7
pixels/sec
   with single, 20x20, SrcOver, !extraalpha, bounce, Default, !xormode, to
VolatileImg(), ident, !alphacolor, width1, antialias, !clip

and with XRender:
Test(graphics.render.tests.fillRect) averaged 2.5252814688096754E7
pixels/sec
   with ident, to VolatileImg(), 1x1, !clip, !extraalpha, width1,
!alphacolor, Default, single, bounce, !antialias, !xormode, SrcOver
All test results:
Test(graphics.render.tests.fillOval) averaged 2.53725229244114E7 pixels/sec
   with ident, to VolatileImg(), 20x20, !clip, !extraalpha, width1,
!alphacolor, Default, single, bounce, antialias, !xormode, SrcOver

To be honest I don't have an explanation why results are *that* good, but
on the other hand - XRender is still clearly faster for 1x1 fillRect and
not *that* much slower for the maskfills.

> There are many ways to improve the OGL pipeline using new OGL feature,
but be aware that currently the OGL
> pipeline is the only one crossplatform pipeline which works virtually on
most of devices(new and old).
> A similar architecture issue exists in the d3d pipeline as well, so maybe
the Vulkan will better,
> it could replace XRender and D3D someday?
>
> I thought Vulkan superseded the OGL, no?

It did and for sure it would be a good/better path forward.
On the other hand it would require a new pipeline implementation and not
just incremental changes, something hard to do in spare-time ;)

Thanks and best regards, Clemens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210117/b87e84c3/attachment.htm>

From bourges.laurent at gmail.com  Sun Jan 17 13:19:36 2021
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sun, 17 Jan 2021 14:19:36 +0100
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work
 concurrently with AWT threads possible? (... the future of the opengl
 pipeline)
In-Reply-To: <CAFvQSYSsYyvn0-3V8-A4ZSmvp2ChpKAfD=cnsYFW_vdHi8YHVw@mail.gmail.com>
References: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
 <b8f4d582-59c2-83d5-f723-a52e64d8004b@oracle.com>
 <CAFvQSYSsYyvn0-3V8-A4ZSmvp2ChpKAfD=cnsYFW_vdHi8YHVw@mail.gmail.com>
Message-ID: <CAKjRUT7_d1PU00QGMyfuKtXPygq+ZvJR10tuXWJ6B9MVTW6Dnw@mail.gmail.com>

Hi Clemens,

I read again the source code and wanted to add metrics like wait_ratio and
make some new heuristics to auto tune the buffer capacity.

I was also tempted to rewrite the buffer overflow strategy: swap buffer or
use a larger one...

Apparently you made another approach (double buffer) to reduce the wait
latency in awt threads... and allow gl thread to run concurently: excellent
!

Le dim. 17 janv. 2021 ? 13:11, Clemens Eisserer <linuxhippy at gmail.com> a
?crit :

> Hi Sergey,
>
> > The design is a little bit different, the XRender pipeline:
> >   - Many threads which call draw operations and sends them to the XServer
> >   - The XSerever decode the the draw operation and push the commands to
> the "opengl buffer"
> >   - Some video driver code which decode the ogl buffer and actually draw
> something
> > The OGL pipeline
> >   - Many threads call draw operations, and save them in the internal
> RenderQueue buffer
> >   - One RenderQueue thread decode the the draw operation and push the
> commands to the "opengl buffer"
> >   - Some video driver code which decode the ogl buffer and actually draw
> something
>
> So in both cases producers (application threads) and the consumer are
> decoupled via some kind of queue (unix domain socket for x11, in-memory
> queue for the renderqueue) and in theory could operate concurrently.
>
> > I am not sure that it work that way, the only way to block the queuing
> thread is to call "flushNow()", for other cases it should not be blocked.
> > The OGLRenderQueue thread however could became blocked every 100ms.
>
> Since there is only one RenderQueue+Buffer, the entire queue has to be
> locked while the commands are processed by the RenderQueue-Thread (via the
> AWT lock held by the thread which is implicitly calling flushNow triggered
> by a full buffer).
> This serverly limits parallelism - you can either process commands
> (RenderQueue thread) or queue new commands (AWT threads) but not both at
> the same time.
> This lead me to the original question - whether this was a necessity
> caused by structural requirements/limitations or whether it simply hasn't
> been thought through / implemented.
>
> I did some prototyping of a double-buffered renderqueue (no other changes)
> over the weekend and results are really promising (1x1 fillRect to measure
> pipeline-overhead, 20x20 aa oval to get an impression data-heavy buffer
> interaction):
>
> Test(graphics.render.tests.fillRect) averaged 1.4837645794468326E7
> pixels/sec
>    with !antialias, to VolatileImg(), ident, SrcOver, single, width1, 1x1,
> !clip, bounce, Default, !xormode, !alphacolor, !extraalpha
> Test(graphics.render.tests.fillOval) averaged 3.896264839428713E7
> pixels/sec
>    with !alphacolor, SrcOver, 20x20, Default, antialias, bounce, !xormode,
> to VolatileImg(), !clip, width1, !extraalpha, single, ident
>
> whereas the original JDK with OGL yielded:
>
> Test(graphics.render.tests.fillRect) averaged 5061909.644344761 pixels/sec
>    with single, 1x1, SrcOver, !extraalpha, bounce, Default, !xormode, to
> VolatileImg(), ident, !alphacolor, width1, !antialias, !clip
> Test(graphics.render.tests.fillOval) averaged 1.0837940280832347E7
> pixels/sec
>    with single, 20x20, SrcOver, !extraalpha, bounce, Default, !xormode, to
> VolatileImg(), ident, !alphacolor, width1, antialias, !clip
>
> and with XRender:
> Test(graphics.render.tests.fillRect) averaged 2.5252814688096754E7
> pixels/sec
>    with ident, to VolatileImg(), 1x1, !clip, !extraalpha, width1,
> !alphacolor, Default, single, bounce, !antialias, !xormode, SrcOver
> All test results:
> Test(graphics.render.tests.fillOval) averaged 2.53725229244114E7 pixels/sec
>    with ident, to VolatileImg(), 20x20, !clip, !extraalpha, width1,
> !alphacolor, Default, single, bounce, antialias, !xormode, SrcOver
>

Could you share your patch to let me study it and try improving it ?

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210117/7b3b45d6/attachment.htm>

From lbourges at openjdk.java.net  Sun Jan 17 13:32:34 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 17 Jan 2021 13:32:34 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v5]
In-Reply-To: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
Message-ID: <CrNErTLVpMGLa1Qe6z3MJYBa_cTVMRSjfS05MPOSRpw=.0644733d-a4db-4360-8d16-430de74f9750@github.com>

> - Removed MarlinRenderingEngine and related classes
> - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
> - Marlin Version set to 0.9.1.4
> 
> Jtreg tests [test/jdk/sun/java2d/marlin/] : OK

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  fixed copyright year again

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2076/files
  - new: https://git.openjdk.java.net/jdk/pull/2076/files/80428a96..8818d050

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

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

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

From linuxhippy at gmail.com  Sun Jan 17 18:58:15 2021
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sun, 17 Jan 2021 19:58:15 +0100
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work
 concurrently with AWT threads possible? (... the future of the opengl
 pipeline)
In-Reply-To: <CAKjRUT7_d1PU00QGMyfuKtXPygq+ZvJR10tuXWJ6B9MVTW6Dnw@mail.gmail.com>
References: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
 <b8f4d582-59c2-83d5-f723-a52e64d8004b@oracle.com>
 <CAFvQSYSsYyvn0-3V8-A4ZSmvp2ChpKAfD=cnsYFW_vdHi8YHVw@mail.gmail.com>
 <CAKjRUT7_d1PU00QGMyfuKtXPygq+ZvJR10tuXWJ6B9MVTW6Dnw@mail.gmail.com>
Message-ID: <CAFvQSYQtiHLfmkCEs0oQttHpwDkt1v0i3rU+BmDDjrqNnzYvnw@mail.gmail.com>

Hi Laurent,

Thanks for your interest in tuning the pipelines and all the work you did
in this regard with Marlin.

> I read again the source code and wanted to add metrics like wait_ratio
and make some new heuristics to auto tune the buffer capacity.
> I was also tempted to rewrite the buffer overflow strategy: swap buffer
or use a larger one...
> Apparently you made another approach (double buffer) to reduce the wait
latency in awt threads... and allow gl thread to run concurently: excellent
!
> Could you share your patch to let me study it and try improving it ?

Sure, I've forked openjdk at: https://github.com/ceisserer/jdk

However please keep in mind this is still very much a proof-of-concept hack
done in one day only:
- There are some places in native code which do not expect the pointer to
the buffer to change after a flush, which are still not modified.
- I guess it would be better to return the new RenderBuffer from
ensureCapacity and flushnow, instead of relying on callers to re-fetch it
after calling those methods
- I am not 100% convinced the rewritten locking in the OglRenderQueue
flusher thread is correct under all circumstances. This code would need a
rewrite/clean-up and error-handling, now that it has to take into account
two different operating modes (sync / async flush). As this has to fit into
AWT's existing locking scheme, it took me some time to get it working.
- there are still rough edges and issues/bugs: when flushNow in
OGLBlitLoops.IsoBlit is changed to flush async, I get crashes etc - so some
places somewhere are either not aware of the buffer change, or expect
certain behaviour I don't know about. (with async flush I get GLX errors
and other strange issues).

just to be curious, are you running the proprietary nvidia opengl driver?

Best regards, Clemens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210117/2faa176a/attachment.htm>

From serb at openjdk.java.net  Mon Jan 18 11:15:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 18 Jan 2021 11:15:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8259681 : Remove the Marlin rendering
 engine (single-precision) [v5]
In-Reply-To: <CrNErTLVpMGLa1Qe6z3MJYBa_cTVMRSjfS05MPOSRpw=.0644733d-a4db-4360-8d16-430de74f9750@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
 <CrNErTLVpMGLa1Qe6z3MJYBa_cTVMRSjfS05MPOSRpw=.0644733d-a4db-4360-8d16-430de74f9750@github.com>
Message-ID: <PHXboAgqwy_jLxBwq0XI69kNmRc6t1xf6YmxTy7BsRU=.8288e519-889d-49a4-bb27-8fac8c4755e4@github.com>

On Sun, 17 Jan 2021 13:32:34 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> - Removed MarlinRenderingEngine and related classes
>> - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
>> - Marlin Version set to 0.9.1.4
>> 
>> Jtreg tests [test/jdk/sun/java2d/marlin/] : OK
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed copyright year again

Marked as reviewed by serb (Reviewer).

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

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

From lbourges at openjdk.java.net  Mon Jan 18 11:37:42 2021
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Mon, 18 Jan 2021 11:37:42 GMT
Subject: [OpenJDK 2D-Dev] Integrated: JDK-8259681 : Remove the Marlin
 rendering engine (single-precision)
In-Reply-To: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
References: <mj3o14LYr5tTydwttBG2EUo4DfuFxTj4OeneD5RLwAs=.83ac945d-c28c-488c-b649-823a11872058@github.com>
Message-ID: <TIX6BaBbbrghnEBvYjM-iWPZJuF0tNVPJ5Vb-Wj7BXI=.ff599873-3a02-4d3c-863f-d3c0349d041d@github.com>

On Thu, 14 Jan 2021 09:27:41 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> - Removed MarlinRenderingEngine and related classes
> - Fixed jtreg tests to remove explicit test runs on MarlinRenderingEngine
> - Marlin Version set to 0.9.1.4
> 
> Jtreg tests [test/jdk/sun/java2d/marlin/] : OK

This pull request has now been integrated.

Changeset: 61292be7
Author:    Laurent Bourg?s <lbourges at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/61292be7
Stats:     9839 lines in 28 files changed: 53 ins; 8694 del; 1092 mod

8259681: Remove the Marlin rendering engine (single-precision)

Reviewed-by: serb

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

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

From Sergey.Bylokhov at oracle.com  Mon Jan 18 12:18:52 2021
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Jan 2021 04:18:52 -0800
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work
 concurrently with AWT threads possible? (... the future of the opengl
 pipeline)
In-Reply-To: <CAFvQSYSsYyvn0-3V8-A4ZSmvp2ChpKAfD=cnsYFW_vdHi8YHVw@mail.gmail.com>
References: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
 <b8f4d582-59c2-83d5-f723-a52e64d8004b@oracle.com>
 <CAFvQSYSsYyvn0-3V8-A4ZSmvp2ChpKAfD=cnsYFW_vdHi8YHVw@mail.gmail.com>
Message-ID: <b1b92c46-26a3-507d-559e-ad164e1019fc@oracle.com>

On 17.01.2021 04:08, Clemens Eisserer wrote:
> To be honest I don't have an explanation why results are *that* good, but on the other hand - XRender is still clearly faster for 1x1 fillRect and not *that* much slower for the maskfills.

It is quite interesting! But it would be good to check what code was affected by this parallelization. I meant we cannot draw much-much faster than OGL draw its primitives, so even w/o parallelization if we will call flush after each fillRect/etc(mimics the in-place rendering on the current thread), we can speed up something but at the end, we will call OGL on one thread.
So executing some code in parallel to the actual OGL rendering we speed up the whole benchmark so much! looks like something(code executed in parallel) works ineffective.


-- 
Best regards, Sergey.

From linuxhippy at gmail.com  Mon Jan 18 12:41:12 2021
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Mon, 18 Jan 2021 13:41:12 +0100
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work
 concurrently with AWT threads possible? (... the future of the opengl
 pipeline)
In-Reply-To: <b1b92c46-26a3-507d-559e-ad164e1019fc@oracle.com>
References: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
 <b8f4d582-59c2-83d5-f723-a52e64d8004b@oracle.com>
 <CAFvQSYSsYyvn0-3V8-A4ZSmvp2ChpKAfD=cnsYFW_vdHi8YHVw@mail.gmail.com>
 <b1b92c46-26a3-507d-559e-ad164e1019fc@oracle.com>
Message-ID: <CAFvQSYTNaokwwohbgU0qiFD7hyOBA1cymEcee7rhe6z5SvP0CA@mail.gmail.com>

Hi Sergey,

It is quite interesting! But it would be good to check what code was
> affected by this parallelization. I meant we cannot draw much-much faster
> than OGL draw its primitives, so even w/o parallelization if we will call
> flush after each fillRect/etc(mimics the in-place rendering on the current
> thread), we can speed up something but at the end, we will call OGL on one
> thread.
> So executing some code in parallel to the actual OGL rendering we speed up
> the whole benchmark so much! looks like something(code executed in
> parallel) works ineffective.
>

Basically, all the pipeline-code on the java-side can now be executed in
parallel with the actual GL calls:
- rasterization of antialiased geometry
- span/scanline generation of non-antialiased geometry
- queue protocol generation
- pipe validation
- actual RenderQueue protocol generation
- all the locking for each & every primitive

So sure, for GPU limited cases this won't help a lot - however, typical
java2d is usually CPU limited with tons of very small primitives and many
state changes in between.

Laurent has done a few benchmarks with mapbench where a ~30% improvement
was achieved. Not mindblowing, but also not that bad:
https://github.com/bourgesl/jdk/wiki/OpenGL-fix-benchmarks

Best regards, Clemens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210118/dd28e5a6/attachment.htm>

From magnus.ihse.bursie at oracle.com  Mon Jan 18 13:21:07 2021
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 18 Jan 2021 14:21:07 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module
In-Reply-To: <20210115102709.538599954@eggemoggin.niobe.net>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <20210115102709.538599954@eggemoggin.niobe.net>
Message-ID: <0219364d-3926-2b7b-4cb5-90f698eeb706@oracle.com>

On 2021-01-15 19:27, mark.reinhold at oracle.com wrote:
> Feature JEPs are living documents until such time as they are delivered.
> In this case it would not be appropriate to update JEP 201, which is as
> much about the transition from the old source-code layout as it is about
> the new layout as of 2014.
>
> At this point, and given that we?d already gone beyond JEP 201 prior to
> this change (with `man` and `lib` subdirectories), what?d make the most
> sense is a new informational JEP that documents the source-code layout.
> Informational JEPs can, within reason, be updated over time.
So I take it I need to create a new informational JEP. :-) Fine, I can 
do that. I assume I mostly need to extract the parts of JEP 201 that 
describes the (then "new") layout, update wording to show that this is a 
description of the current layout, and add the new additions.

It'll be a very short JEP, but in this case, that's probably a virtue.

/Magnus

From ihse at openjdk.java.net  Mon Jan 18 13:47:20 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 18 Jan 2021 13:47:20 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module [v5]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <VOISxSWArxxc_b4jkanMxAHICUEnv3wmh7yub1so5yg=.f062b37b-e0ef-4362-be5f-f73f170f3438@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Move characterdata templates to share/classes/java/lang.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/68b252b5..c4894348

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

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

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

From ihse at openjdk.java.net  Mon Jan 18 13:49:49 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 18 Jan 2021 13:49:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module [v4]
In-Reply-To: <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
 <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
Message-ID: <JqU9ob7JdM95DwwPcGJTrFB-r1b8QTl5Y8GijSHLoCc=.829f75d9-a1de-47db-8b58-f4fe2d312a2a@github.com>

On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang?

@AlanBateman When I moved the charset templates, I found this gold nugget:

# Copy two Java files that need no preprocessing.
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template
	$(call LogInfo, Generating $(@F))
	$(call install-file)

GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \
    $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java

What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now.

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

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

From Sergey.Bylokhov at oracle.com  Mon Jan 18 22:52:28 2021
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 18 Jan 2021 14:52:28 -0800
Subject: [OpenJDK 2D-Dev] Making the OpenGL-Queue-Flusher work
 concurrently with AWT threads possible? (... the future of the opengl
 pipeline)
In-Reply-To: <CAFvQSYTNaokwwohbgU0qiFD7hyOBA1cymEcee7rhe6z5SvP0CA@mail.gmail.com>
References: <CAFvQSYS-dfmSU5wfK0AcvayYM619wO=0e0H9LW_XzMTU1QsQ9w@mail.gmail.com>
 <b8f4d582-59c2-83d5-f723-a52e64d8004b@oracle.com>
 <CAFvQSYSsYyvn0-3V8-A4ZSmvp2ChpKAfD=cnsYFW_vdHi8YHVw@mail.gmail.com>
 <b1b92c46-26a3-507d-559e-ad164e1019fc@oracle.com>
 <CAFvQSYTNaokwwohbgU0qiFD7hyOBA1cymEcee7rhe6z5SvP0CA@mail.gmail.com>
Message-ID: <c4db769c-420e-c224-ea88-58c5419aff60@oracle.com>

On 18.01.2021 04:41, Clemens Eisserer wrote:
> So sure, for GPU limited cases this won't help a lot - however, typical java2d is usually CPU limited with tons of very small primitives and many state changes in between.

It does not affect so much the xrender which do the same CPU related steps, but this speeds up so !much! OGL if executed in parallel.
I think the benchmark is cheating here, it does not call XSync nor glflush for each operation, so it just checks the speed of pushing the data to the buffer, and not measured the actual rendering for both pipelines, unlike the software-based rendering.


-- 
Best regards, Sergey.

From serb at openjdk.java.net  Tue Jan 19 09:54:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 19 Jan 2021 09:54:00 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8239894: Xserver crashes when the wrong high
 refresh rate is used
Message-ID: <eOmM99_QyDZFu3RgPiEQzfysion1Ot4KuQ-V7tM3UMw=.3f47279f-cecc-4303-940a-c12821d70979@github.com>

We use two different approaches to listing the display modes on the system:
 - For single-screen configuration use version 1.1 protocol XRRGetScreenInfo/XRRConfigRates/XRRConfigSizes
 - For multi-screen configuration use version 1.2 protocol: XRRGetScreenResources/XRRGetOutputInfo/XRRModeInfo

Unfortunately, the current code does not work for some specific double scan modes, it doubles the real refresh rate. If this refresh rate will be passed to the Xserver later it could hang/crash.

The same bug existed in xrandr utility before version 1.4:
https://bugs.freedesktop.org/show_bug.cgi?id=37043
https://gitlab.freedesktop.org/xorg/app/xrandr/commit/7fd4f18b649f22fad4dbf9fc64b69b3e7f172207

As suggested in the bug report I have tried to unify the code for single and multiscreen systems and use updated code currently used on the multiscreen.

But unfortunately, I have found that the multi-screen code is even more broken. The problematic code is this:

    int scr = 0, out = 0;
    if (usingXinerama && XScreenCount(awt_display) > 0) {
        out = screen;
    } else {
        scr = screen;
    }
The idea of the code is: if the passed screen is Xinerama index used by the java2d, then the "scr" will be zero, and "out" will be the "virtual" index for that screen. If the screen is X11 screen then "src" will be the correct screen and "out" will be zero.

The problem is that the code assumes that xrandr expect the "virtual" index as the "out" parameter, but this is not. This parameter is the index of the "output" such as DP1, DP2, other ports/etc.

So sometimes the code works when the first screen is connected to the first port on the video card and the second screen to the second port, otherwise, we just report data for the wrong screen or report nothing.

I did not found a reliable way to map Xinerama srceens to the xrandr. It is better to rework the java2d to use the xrandr instead of xinerama.

As a fix, I suggest dropping the code which uses the incorrect mapping screen->output. This includes the code related to the display modes added in the JDK-8167486 + JDK-8022810, and also the code related to the calculation of scale factor from the "ubuntu property" which does not work on the recent ubuntu version after migration to gnome3 added in the JDK-8149115

I will file a separate two bugs to reimplement this functionality, most probably the "display modes" will be implementing when we fully migrate to the xrandr, and calculation of the scale factor will be implemented via the gtk library.

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

Commit messages:
 - Report the current mode in the list of supported modes in xinerama
 - Rollback JDK-8149115, JDK-8167486, JDK-8022810

Changes: https://git.openjdk.java.net/jdk/pull/2136/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2136&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8239894
  Stats: 310 lines in 5 files changed: 3 ins; 292 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2136.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2136/head:pull/2136

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

From serb at openjdk.java.net  Thu Jan 21 02:38:14 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 21 Jan 2021 02:38:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6606673: Path2D.Double,
 Path2D.Float and GeneralPath ctors throw exception when
 initialCapacity is negative
Message-ID: <jfDwXHyb_Hyb2REogHuRLy0WM91GMLPvNujaorXWH2Y=.7f7dbd30-78d5-46eb-81b3-d32455fc0631@github.com>

The specification for Path2D.Double, Path2D.Float and GeneralPath constructors is updated. NegativeArraySizeException, IllegalArgumentException and NullPointerException are added.

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

Commit messages:
 - Initial fix

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

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

From psadhukhan at openjdk.java.net  Thu Jan 21 05:03:49 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 21 Jan 2021 05:03:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6606673: Path2D.Double,
 Path2D.Float and GeneralPath ctors throw exception when
 initialCapacity is negative
In-Reply-To: <jfDwXHyb_Hyb2REogHuRLy0WM91GMLPvNujaorXWH2Y=.7f7dbd30-78d5-46eb-81b3-d32455fc0631@github.com>
References: <jfDwXHyb_Hyb2REogHuRLy0WM91GMLPvNujaorXWH2Y=.7f7dbd30-78d5-46eb-81b3-d32455fc0631@github.com>
Message-ID: <EIKIMOj1p8SZWNjrDbmGNDTc_SA1cXRAkaw7e7UyjhI=.89716860-e853-4931-a708-291758e5f848@github.com>

On Thu, 21 Jan 2021 00:50:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The specification for Path2D.Double, Path2D.Float and GeneralPath constructors is updated. NegativeArraySizeException, IllegalArgumentException and NullPointerException are added.

Marked as reviewed by psadhukhan (Reviewer).

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

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

From kizune at openjdk.java.net  Thu Jan 21 05:12:54 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 21 Jan 2021 05:12:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6606673: Path2D.Double,
 Path2D.Float and GeneralPath ctors throw exception when
 initialCapacity is negative
In-Reply-To: <jfDwXHyb_Hyb2REogHuRLy0WM91GMLPvNujaorXWH2Y=.7f7dbd30-78d5-46eb-81b3-d32455fc0631@github.com>
References: <jfDwXHyb_Hyb2REogHuRLy0WM91GMLPvNujaorXWH2Y=.7f7dbd30-78d5-46eb-81b3-d32455fc0631@github.com>
Message-ID: <UlLqutLFc5YneTz7oZYmHsNamYBU1yMDRZZxaY_zkNs=.19d6a8ed-e547-4636-8788-ed4aa6063f3a@github.com>

On Thu, 21 Jan 2021 00:50:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The specification for Path2D.Double, Path2D.Float and GeneralPath constructors is updated. NegativeArraySizeException, IllegalArgumentException and NullPointerException are added.

Marked as reviewed by kizune (Reviewer).

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

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

From kizune at openjdk.java.net  Thu Jan 21 05:18:54 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 21 Jan 2021 05:18:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8239894: Xserver crashes when the wrong
 high refresh rate is used
In-Reply-To: <eOmM99_QyDZFu3RgPiEQzfysion1Ot4KuQ-V7tM3UMw=.3f47279f-cecc-4303-940a-c12821d70979@github.com>
References: <eOmM99_QyDZFu3RgPiEQzfysion1Ot4KuQ-V7tM3UMw=.3f47279f-cecc-4303-940a-c12821d70979@github.com>
Message-ID: <HnCFoyf-0VvZ46Aw23I_p_ubNAeVt_z42rqDTm2PXHM=.ff3e2764-878d-4a5a-b835-e99aabe98178@github.com>

On Tue, 19 Jan 2021 00:57:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We use two different approaches to listing the display modes on the system:
>  - For single-screen configuration use version 1.1 protocol XRRGetScreenInfo/XRRConfigRates/XRRConfigSizes
>  - For multi-screen configuration use version 1.2 protocol: XRRGetScreenResources/XRRGetOutputInfo/XRRModeInfo
> 
> Unfortunately, the current code does not work for some specific double scan modes, it doubles the real refresh rate. If this refresh rate will be passed to the Xserver later it could hang/crash.
> 
> The same bug existed in xrandr utility before version 1.4:
> https://bugs.freedesktop.org/show_bug.cgi?id=37043
> https://gitlab.freedesktop.org/xorg/app/xrandr/commit/7fd4f18b649f22fad4dbf9fc64b69b3e7f172207
> 
> As suggested in the bug report I have tried to unify the code for single and multiscreen systems and use updated code currently used on the multiscreen.
> 
> But unfortunately, I have found that the multi-screen code is even more broken. The problematic code is this:
> 
>     int scr = 0, out = 0;
>     if (usingXinerama && XScreenCount(awt_display) > 0) {
>         out = screen;
>     } else {
>         scr = screen;
>     }
> The idea of the code is: if the passed screen is Xinerama index used by the java2d, then the "scr" will be zero, and "out" will be the "virtual" index for that screen. If the screen is X11 screen then "src" will be the correct screen and "out" will be zero.
> 
> The problem is that the code assumes that xrandr expect the "virtual" index as the "out" parameter, but this is not. This parameter is the index of the "output" such as DP1, DP2, other ports/etc.
> 
> So sometimes the code works when the first screen is connected to the first port on the video card and the second screen to the second port, otherwise, we just report data for the wrong screen or report nothing.
> 
> I did not found a reliable way to map Xinerama srceens to the xrandr. It is better to rework the java2d to use the xrandr instead of xinerama.
> 
> As a fix, I suggest dropping the code which uses the incorrect mapping screen->output. This includes the code related to the display modes added in the JDK-8167486 + JDK-8022810, and also the code related to the calculation of scale factor from the "ubuntu property" which does not work on the recent ubuntu version after migration to gnome3 added in the JDK-8149115
> 
> I will file a separate two bugs to reimplement this functionality, most probably the "display modes" will be implementing when we fully migrate to the xrandr, and calculation of the scale factor will be implemented via the gtk library.

I guess not having this functionality at all is better than having a code that hangs. Can we have these new bugs about re-implementing this functionality linked in the initial bug so they can be tracked easier?

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

Marked as reviewed by kizune (Reviewer).

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

From prr at openjdk.java.net  Thu Jan 21 15:58:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 21 Jan 2021 15:58:35 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259869: [macOS] Remove desktop module
 dependencies on JNF Reference APIs
In-Reply-To: <BdKXgBEjuo8QIlIOWbz04oa9qor_eHxiFFGjihFlWXo=.b14dc0cd-8d4d-4219-aad1-f1a6b89c8b27@github.com>
References: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
 <BdKXgBEjuo8QIlIOWbz04oa9qor_eHxiFFGjihFlWXo=.b14dc0cd-8d4d-4219-aad1-f1a6b89c8b27@github.com>
Message-ID: <2LpmfCGqLhdLNlvFIrgycqOOgQi2cJx0OZk6E15zgBE=.26f9fe00-bf88-42b1-b61e-5efc693d9bc7@github.com>

On Wed, 20 Jan 2021 06:02:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This removes desktop module usage of the JNF JNI reference convenience APIs
>> These are simply a direct conversion
>> JNFNewGlobalRef 
>> JNFDeleteGlobalRef 
>> JNFNewWeakGlobalRef 
>> JNFDeleteWeakGlobalRef 
>> 
>> These two
>> JNFJObjectWrapper 
>> JNFWeakJObjectWrapper 
>> exist to allow clean up of the refs when a Cocoa wrapper object is released.
>> However in all cases there are more direct ways to clean it up and in at least one usage
>> the existing code directly releases it with the comment that this is more efficient.
>> 
>> All our automated regression and JCK tests pass with this change.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 1547:
> 
>> 1545:         AWTWindow *awtWindow = [AWTWindow getTopmostWindowUnderMouse];
>> 1546:         if (awtWindow != nil) {
>> 1547:             topmostWindowUnderMouse = awtWindow.javaPlatformWindow;
> 
> I wonder what type of "reference" we should return here, I do not remember how the "NewWeakGlobalRef" behave when returned to java.

It is no different than other cases. Java will get a new strong ref to the object
and expect it to be of the return type of this native method.

> src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m line 58:
> 
>> 56:     jobject gTriggerEvent = (*env)->NewGlobalRef(env, jtrigger);
>> 57:     jlongArray gFormats = (*env)->NewGlobalRef(env, jformats);
>> 58:     jobject gFormatMap = (*env)->NewGlobalRef(env, jformatmap);
> 
> All above should be checked for NULL since OOM may occur, but it looks like it does not throw OOM?
> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#NewGlobalRef

It is the case that per even the latest spec. none of these throw any exception.
https://docs.oracle.com/en/java/javase/15/docs/specs/jni/functions.html#newglobalref
So I think the existing code doesn't do anything in the event of a NULL return.
And if you want to check for NULL here and return NULL from the native method there's semantic implications that require the caller never pass NULL for any of these.
It is not illegal to pass NULL to NewGlobalRef.
Investigating and confirming that is beyond the scope of this change.
Or we make the code a bit more complex here and check that we get back non-null for a non-null arg. But once again nothing new here.

> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.h line 55:
> 
>> 53: @property (nonatomic, retain) NSWindow *nsWindow;
>> 54: 
>> 55: @property (nonatomic) jobject javaPlatformWindow;
> 
> I think it will be useful to have a comment here that this value is a weak reference and should be copied to the local ref before usage.

I suppose I can add a comment ... but it is already done in the couple of dozen usages so any one adding a new usage who misses that will likely miss the comment too.

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

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

From prr at openjdk.java.net  Thu Jan 21 16:28:19 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 21 Jan 2021 16:28:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259869: [macOS] Remove desktop module
 dependencies on JNF Reference APIs [v2]
In-Reply-To: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
References: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
Message-ID: <AfQYxLuSbpCkD2FiXE4QsmxFoNL5Pknz8RHHC3UynNU=.2dfe6a9b-1c37-41cb-b505-0cf816366b27@github.com>

> This removes desktop module usage of the JNF JNI reference convenience APIs
> These are simply a direct conversion
> JNFNewGlobalRef 
> JNFDeleteGlobalRef 
> JNFNewWeakGlobalRef 
> JNFDeleteWeakGlobalRef 
> 
> These two
> JNFJObjectWrapper 
> JNFWeakJObjectWrapper 
> exist to allow clean up of the refs when a Cocoa wrapper object is released.
> However in all cases there are more direct ways to clean it up and in at least one usage
> the existing code directly releases it with the comment that this is more efficient.
> 
> All our automated regression and JCK tests pass with this change.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2133/files
  - new: https://git.openjdk.java.net/jdk/pull/2133/files/61d6476b..6a9e7a0d

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

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

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

From serb at openjdk.java.net  Fri Jan 22 00:25:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Jan 2021 00:25:56 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8239894: Xserver crashes when the
 wrong high refresh rate is used
In-Reply-To: <eOmM99_QyDZFu3RgPiEQzfysion1Ot4KuQ-V7tM3UMw=.3f47279f-cecc-4303-940a-c12821d70979@github.com>
References: <eOmM99_QyDZFu3RgPiEQzfysion1Ot4KuQ-V7tM3UMw=.3f47279f-cecc-4303-940a-c12821d70979@github.com>
Message-ID: <mQpV1EGVAP0MA4g4iyKxFMysshVv7wbPk7OgWANm0n8=.16033fe7-f4e5-4002-a015-da70eea3683d@github.com>

On Tue, 19 Jan 2021 00:57:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We use two different approaches to listing the display modes on the system:
>  - For single-screen configuration use version 1.1 protocol XRRGetScreenInfo/XRRConfigRates/XRRConfigSizes
>  - For multi-screen configuration use version 1.2 protocol: XRRGetScreenResources/XRRGetOutputInfo/XRRModeInfo
> 
> Unfortunately, the current code does not work for some specific double scan modes, it doubles the real refresh rate. If this refresh rate will be passed to the Xserver later it could hang/crash.
> 
> The same bug existed in xrandr utility before version 1.4:
> https://bugs.freedesktop.org/show_bug.cgi?id=37043
> https://gitlab.freedesktop.org/xorg/app/xrandr/commit/7fd4f18b649f22fad4dbf9fc64b69b3e7f172207
> 
> As suggested in the bug report I have tried to unify the code for single and multiscreen systems and use updated code currently used on the multiscreen.
> 
> But unfortunately, I have found that the multi-screen code is even more broken. The problematic code is this:
> 
>     int scr = 0, out = 0;
>     if (usingXinerama && XScreenCount(awt_display) > 0) {
>         out = screen;
>     } else {
>         scr = screen;
>     }
> The idea of the code is: if the passed screen is Xinerama index used by the java2d, then the "scr" will be zero, and "out" will be the "virtual" index for that screen. If the screen is X11 screen then "src" will be the correct screen and "out" will be zero.
> 
> The problem is that the code assumes that xrandr expect the "virtual" index as the "out" parameter, but this is not. This parameter is the index of the "output" such as DP1, DP2, other ports/etc.
> 
> So sometimes the code works when the first screen is connected to the first port on the video card and the second screen to the second port, otherwise, we just report data for the wrong screen or report nothing.
> 
> I did not found a reliable way to map Xinerama srceens to the xrandr. It is better to rework the java2d to use the xrandr instead of xinerama.
> 
> As a fix, I suggest dropping the code which uses the incorrect mapping screen->output. This includes the code related to the display modes added in the JDK-8167486 + JDK-8022810, and also the code related to the calculation of scale factor from the "ubuntu property" which does not work on the recent ubuntu version after migration to gnome3 added in the JDK-8149115
> 
> I will file a separate two bugs to reimplement this functionality, most probably the "display modes" will be implementing when we fully migrate to the xrandr, and calculation of the scale factor will be implemented via the gtk library.

This pull request has now been integrated.

Changeset: a7c2ebc7
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a7c2ebc7
Stats:     310 lines in 5 files changed: 3 ins; 292 del; 15 mod

8239894: Xserver crashes when the wrong high refresh rate is used

Reviewed-by: kizune

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

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

From serb at openjdk.java.net  Fri Jan 22 01:22:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Jan 2021 01:22:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8259869: [macOS] Remove desktop module
 dependencies on JNF Reference APIs [v2]
In-Reply-To: <AfQYxLuSbpCkD2FiXE4QsmxFoNL5Pknz8RHHC3UynNU=.2dfe6a9b-1c37-41cb-b505-0cf816366b27@github.com>
References: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
 <AfQYxLuSbpCkD2FiXE4QsmxFoNL5Pknz8RHHC3UynNU=.2dfe6a9b-1c37-41cb-b505-0cf816366b27@github.com>
Message-ID: <JLeqiWR-nCpZeVhOB9-VGVkhXxXiJt5cftHwIbW2law=.572d5124-843e-476b-bb7d-703c01243072@github.com>

On Thu, 21 Jan 2021 16:28:19 GMT, Phil Race <prr at openjdk.org> wrote:

>> This removes desktop module usage of the JNF JNI reference convenience APIs
>> These are simply a direct conversion
>> JNFNewGlobalRef 
>> JNFDeleteGlobalRef 
>> JNFNewWeakGlobalRef 
>> JNFDeleteWeakGlobalRef 
>> 
>> These two
>> JNFJObjectWrapper 
>> JNFWeakJObjectWrapper 
>> exist to allow clean up of the refs when a Cocoa wrapper object is released.
>> However in all cases there are more direct ways to clean it up and in at least one usage
>> the existing code directly releases it with the comment that this is more efficient.
>> 
>> All our automated regression and JCK tests pass with this change.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs

Marked as reviewed by serb (Reviewer).

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

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

From prr at openjdk.java.net  Fri Jan 22 01:55:58 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Jan 2021 01:55:58 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8259869: [macOS] Remove desktop module
 dependencies on JNF Reference APIs
In-Reply-To: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
References: <D2p15HR3Un60LWe1Z_AQWgaKYiNx6XXL3j2EFpu-BCk=.b73c3c14-1bce-4837-8c06-771416fd83c2@github.com>
Message-ID: <FfX-lFywRZFbBKISx9Lsyrl7hKiUfL_yVAeW53vJzSk=.89301b4d-5671-484e-a9a5-a6004b4885d4@github.com>

On Mon, 18 Jan 2021 16:08:37 GMT, Phil Race <prr at openjdk.org> wrote:

> This removes desktop module usage of the JNF JNI reference convenience APIs
> These are simply a direct conversion
> JNFNewGlobalRef 
> JNFDeleteGlobalRef 
> JNFNewWeakGlobalRef 
> JNFDeleteWeakGlobalRef 
> 
> These two
> JNFJObjectWrapper 
> JNFWeakJObjectWrapper 
> exist to allow clean up of the refs when a Cocoa wrapper object is released.
> However in all cases there are more direct ways to clean it up and in at least one usage
> the existing code directly releases it with the comment that this is more efficient.
> 
> All our automated regression and JCK tests pass with this change.

This pull request has now been integrated.

Changeset: 92c2f084
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/92c2f084
Stats:     153 lines in 21 files changed: 19 ins; 7 del; 127 mod

8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs

Reviewed-by: serb

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

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

From serb at openjdk.java.net  Fri Jan 22 10:35:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Jan 2021 10:35:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException [v5]
In-Reply-To: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
Message-ID: <kJIfU1JhwAlEQSmgnBMF0V8VnaCDsn3sJ1ghHu_BqJU=.f016f2c7-a7a0-420d-af0e-328d97f85322@github.com>

> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
> 
> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
> 
> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
> 
> Notes about the link above:
> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
> 
> The fix:
>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
> 
> See some comments inline.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Update ProfileActivationDuringPropertyAccess.java
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Delete the DeferralMgr machinery
 - Update ICC_Profile.java
 - Wrong spec in ProfileDeferralInfo
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/14522800...ecfc1ed8

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

Changes: https://git.openjdk.java.net/jdk/pull/1613/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1613&range=04
  Stats: 520 lines in 9 files changed: 183 ins; 265 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1613/head:pull/1613

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

From akozlov at openjdk.java.net  Fri Jan 22 20:02:56 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 22 Jan 2021 20:02:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port
Message-ID: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@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)

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

Commit messages:
 - Fix build
 - JDK-8253816: Update after recent changes
 - Rework gtests to always have wx_write
 - Revert gtest changes
 - Fix gtests in debug
 - Merge remote-tracking branch 'upstream/master' into jdk-macos
 - Fix windows_aarch64
 - Use r18_tls instead of r18_reserved
 - JDK-8253742: bsd_aarch64 part
 - JDK-8257882: bsd_aarch64 part
 - ... and 40 more: https://git.openjdk.java.net/jdk/compare/82adfb32...3d4f4c23

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253795
  Stats: 3335 lines in 117 files changed: 3230 ins; 41 del; 64 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 Jan 22 20:04:02 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 22 Jan 2021 20:04:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8240247: No longer need to wrap files with
 contentContainer
Message-ID: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>

[JDK-8231144](https://bugs.openjdk.java.net/browse/JDK-8231144) wrapped the contents of plain HTML documents into `<div class="contentContainer">` to apply the styles and add the margins around the content for a consistent look.

This is no longer necessary after [JDK-8239817](https://bugs.openjdk.java.net/browse/JDK-8239817) was fixed.

These documents looks fine without being wrapped. So this fix basically undoes changes under JDK-8231144 and removes the redundant `<div>` wrapper element.

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

Commit messages:
 - Remove contentContainer wrapper

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

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

From serb at openjdk.java.net  Fri Jan 22 20:14:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 22 Jan 2021 20:14:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8240247: No longer need to wrap files
 with contentContainer
In-Reply-To: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>
References: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>
Message-ID: <OebNzkpRqT4MbTTQd4n4bAgMH6y5UwSyB3Z_rnFS5HY=.e5342598-aa26-4b97-8d6c-1760a0eb452a@github.com>

On Fri, 22 Jan 2021 19:50:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8231144](https://bugs.openjdk.java.net/browse/JDK-8231144) wrapped the contents of plain HTML documents into `<div class="contentContainer">` to apply the styles and add the margins around the content for a consistent look.
> 
> This is no longer necessary after [JDK-8239817](https://bugs.openjdk.java.net/browse/JDK-8239817) was fixed.
> 
> These documents looks fine without being wrapped. So this fix basically undoes changes under JDK-8231144 and removes the redundant `<div>` wrapper element.

Marked as reviewed by serb (Reviewer).

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

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

From erikj at openjdk.java.net  Fri Jan 22 20:27:42 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 22 Jan 2021 20:27:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 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: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@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)

Build changes in general look good.

make/autoconf/flags-cflags.m4 line 169:

> 167:       WARNINGS_ENABLE_ALL="-Wall -Wextra -Wformat=2 $WARNINGS_ENABLE_ADDITIONAL"
> 168: 
> 169:       DISABLED_WARNINGS="unknown-warning-option unused-parameter unused format-nonliteral"

Globally disabling a warning needs some motivation. Why is this needed? Does it really need to be applied everywhere or is there a specific binary or source file where this is triggered?

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

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

From alanb at openjdk.java.net  Sat Jan 23 07:57:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 23 Jan 2021 07:57:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module [v4]
In-Reply-To: <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
 <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
Message-ID: <ad2uU37xBO8wpE-w6Ogj3paBihqfXiKLRJ627VwNgkc=.1d6a7573-d606-4eb1-ba21-5daaf47c485c@github.com>

On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to src/java.base/share/classes/java/lang?

> @AlanBateman When I moved the charset templates, I found this gold nugget:
> 
> ```
> # Copy two Java files that need no preprocessing.
> $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template
> 	$(call LogInfo, Generating $(@F))
> 	$(call install-file)
> 
> GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \
>     $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java
> ```
> 
> What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now.

Good find, surprised this wasn't spotted before now. We should create a separate issue to rename them and get rid of the copying in the make file.

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

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

From aivanov at openjdk.java.net  Sat Jan 23 11:40:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 23 Jan 2021 11:40:39 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8240247: No longer need to wrap files
 with contentContainer
In-Reply-To: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>
References: <MFwS33I1hyEjvrcgku75FpvmBqhBUZWrQN-vKuYxlis=.e8f6ff59-75a2-4a88-854b-771f6c286174@github.com>
Message-ID: <os42JCT7FvcBC4zyHuQ76264EZkfn7-bqKwnIabRhRU=.0920c1cb-01c2-4c38-ab3c-3ba0d4b01c82@github.com>

On Fri, 22 Jan 2021 19:50:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> [JDK-8231144](https://bugs.openjdk.java.net/browse/JDK-8231144) wrapped the contents of plain HTML documents into `<div class="contentContainer">` to apply the styles and add the margins around the content for a consistent look.
> 
> This is no longer necessary after [JDK-8239817](https://bugs.openjdk.java.net/browse/JDK-8239817) was fixed.
> 
> These documents looks fine without being wrapped. So this fix basically undoes changes under JDK-8231144 and removes the redundant `<div>` wrapper element.

This pull request has now been integrated.

Changeset: f624dba6
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f624dba6
Stats:     45 lines in 15 files changed: 0 ins; 30 del; 15 mod

8240247: No longer need to wrap files with contentContainer

Reviewed-by: serb

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

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

From aph at openjdk.java.net  Sat Jan 23 11:46:45 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 23 Jan 2021 11:46:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 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: <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@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)

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86:

> 84: 
> 85:   switch (_num_int_args) {
> 86:   case 0:

I don't think you need such a large switch statement. I think this can be expressed as
if (num_int_args <= 6) {
    ldr(as_Register(num_int_args + 1), src);
... etc.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 43:

> 41: //describe amount of space in bytes occupied by type on native stack
> 42: #ifdef __APPLE__
> 43:     const int nativeByteSpace        = sizeof(jbyte);

I'm not sure these names should be in the global name space, and they're not very descriptive. Something like NativeStack::byteSpace would be better. Then you can use them with a `using namespace NativeStack` declaration.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 433:

> 431:       store_and_inc(_to, from_obj, nativeShortSpace);
> 432: 
> 433:       _num_int_args++;

Please lift this increment out of the conditional.

src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394:

> 392: 
> 393: class SlowSignatureHandler
> 394:   : public NativeSignatureIterator {

SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and=paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants.

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

> 5270: void MacroAssembler::get_thread(Register dst) {
> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
> 5272:   push(saved_regs, sp);

This isn't very nice.

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

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

From aivanov at openjdk.java.net  Sat Jan 23 19:10:46 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 23 Jan 2021 19:10:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables with CSS
Message-ID: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>

Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
table {border: outset 1px}
th, td {border: inset 1px} 

These declarations produce the same rendering as the default one in Firefox and Edge. 

Another option is to use `solid` in both cases.

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

Commit messages:
 - Move table styles to common <style> block
 - 8260314: Replace border="1" on tables with CSS

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

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

From akozlov at openjdk.java.net  Sun Jan 24 15:32:59 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 24 Jan 2021 15:32:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
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: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@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 two additional commits since the last revision:

 - Address feedback for signature generators
 - Enable -Wformat-nonliteral back

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/3d4f4c23..50b55f66

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

  Stats: 204 lines in 2 files changed: 20 ins; 138 del; 46 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  Sun Jan 24 15:37:43 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 24 Jan 2021 15:37:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <_l6v7_5ODWCmW5x90hA_Vv0TegGm00YW98ELrJvi65o=.1b2d4f0f-0791-4d4f-bf00-d829738611b5@github.com>
Message-ID: <MylmP-IiIBnIAr9adMFRhhr4DBaZQmIM1refrIQMLVE=.0fc0d779-8c56-45ee-9adb-338fdc6ecb70@github.com>

On Fri, 22 Jan 2021 20:18:51 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> make/autoconf/flags-cflags.m4 line 169:
> 
>> 167:       WARNINGS_ENABLE_ALL="-Wall -Wextra -Wformat=2 $WARNINGS_ENABLE_ADDITIONAL"
>> 168: 
>> 169:       DISABLED_WARNINGS="unknown-warning-option unused-parameter unused format-nonliteral"
> 
> Globally disabling a warning needs some motivation. Why is this needed? Does it really need to be applied everywhere or is there a specific binary or source file where this is triggered?

It seems to be a leftover from the past. I tried to revert the line and the build went fine. Thanks for noticing!

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

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

From akozlov at openjdk.java.net  Sun Jan 24 15:52:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 24 Jan 2021 15:52:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
Message-ID: <FIAu02KPkeT8mjt2BKIcVnei38gRk3aoXWTfpIvFhos=.773b9848-15d8-45b5-9669-4df8ca65b2d0@github.com>

On Sat, 23 Jan 2021 11:10:17 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86:
> 
>> 84: 
>> 85:   switch (_num_int_args) {
>> 86:   case 0:
> 
> I don't think you need such a large switch statement. I think this can be expressed as
> if (num_int_args <= 6) {
>     ldr(as_Register(num_int_args + r1.encoding()), src);
> ... etc.

I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122

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

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

From akozlov at openjdk.java.net  Sun Jan 24 16:13:42 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 24 Jan 2021 16:13:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
Message-ID: <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>

On Sat, 23 Jan 2021 11:42:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394:
> 
>> 392: 
>> 393: class SlowSignatureHandler
>> 394:   : public NativeSignatureIterator {
> 
> SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and-paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants.

Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements.

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

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

From vkempik at openjdk.java.net  Sun Jan 24 16:32:41 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Sun, 24 Jan 2021 16:32:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
Message-ID: <UubbyJKBR24lG2v3vsTotl7bRFQrHWypAM58MRRy5Tc=.15f12745-172c-401e-8966-2e5b7137b9fc@github.com>

On Sat, 23 Jan 2021 11:43:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272:
> 
>> 5270: void MacroAssembler::get_thread(Register dst) {
>> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
>> 5272:   push(saved_regs, sp);
> 
> This isn't very nice.

Hello
Why is it not nice ?
linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s
which clobbers only r0 and r1
macos_aarch64 has no such tls code and uses generic C-call to Thread::current();
Hence we  are saving possibly clobbered regs here.

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

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

From aph at openjdk.java.net  Mon Jan 25 10:00:41 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 25 Jan 2021 10:00:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>
Message-ID: <GUQ9iV90tXzdUOtyjcIJygM7qBCcUtSHVOol8hOK2OE=.7b3ab947-f835-43d4-a852-cde094efbf62@github.com>

On Sun, 24 Jan 2021 16:10:44 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 394:
>> 
>>> 392: 
>>> 393: class SlowSignatureHandler
>>> 394:   : public NativeSignatureIterator {
>> 
>> SlowSignatureHandler is turning into a maintenance nightmare. This isn't the fault of this commit so much as some nasty cut-and-paste programming in the code you're editing. It might well be better to rewrite this whole thing to use a table-driven approach, with a table that contains the increment and the size of each native type: then we'd have only a single routine which could pass data of any type, and each OS needs only supply a table of constants.
>
> Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements.

I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline.

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

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

From aph at openjdk.java.net  Mon Jan 25 10:00:43 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 25 Jan 2021 10:00:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <UubbyJKBR24lG2v3vsTotl7bRFQrHWypAM58MRRy5Tc=.15f12745-172c-401e-8966-2e5b7137b9fc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <UubbyJKBR24lG2v3vsTotl7bRFQrHWypAM58MRRy5Tc=.15f12745-172c-401e-8966-2e5b7137b9fc@github.com>
Message-ID: <UKJs_0siqUqR9HgIbFpiReb_i9ASyFf8Uwo1rS9ETbM=.495a5d37-0069-4c63-8487-d64f0d14d5b2@github.com>

On Sun, 24 Jan 2021 16:29:31 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5272:
>> 
>>> 5270: void MacroAssembler::get_thread(Register dst) {
>>> 5271:   RegSet saved_regs = RegSet::range(r0, r1) + BSD_ONLY(RegSet::range(r2, r17)) + lr - dst;
>>> 5272:   push(saved_regs, sp);
>> 
>> This isn't very nice.
>
> Hello
> Why is it not nice ?
> linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s
> which clobbers only r0 and r1
> macos_aarch64 has no such tls code and uses generic C-call to Thread::current();
> Hence we  are saving possibly clobbered regs here.

Surely if you did as Linux does you wouldn't need to clobber all those registers.

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

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

From aivanov at openjdk.java.net  Mon Jan 25 11:52:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 25 Jan 2021 11:52:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables
 with CSS
In-Reply-To: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
Message-ID: <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>

On Sat, 23 Jan 2021 19:06:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
> table {border: outset 1px}
> th, td {border: inset 1px} 
> 
> These declarations produce the same rendering as the default one in Firefox and Edge. 
> 
> Another option is to use `solid` in both cases.

@jonathan-gibbons, what do you think?

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

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

From ihse at openjdk.java.net  Mon Jan 25 13:25:53 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 25 Jan 2021 13:25:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
Message-ID: <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>

On Sun, 24 Jan 2021 15:32:59 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:
> 
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

Changes requested by ihse (Reviewer).

make/autoconf/jvm-features.m4 line 269:

> 267:     if test "x$OPENJDK_TARGET_OS" != xaix && \
> 268:         !( test "x$OPENJDK_TARGET_OS" = "xmacosx" && \
> 269:         test "x$OPENJDK_TARGET_CPU" = "xaarch64" ) ; then

This test is making my head spin. Can't you just invert it to this structure:

if OS=aix || OS+CPU = mac+aarch64; then
  no
else
 yes
fi

make/autoconf/platform.m4 line 75:

> 73:         ;;
> 74:       esac
> 75:       ;;

This is solved in the wrong place. This code should just use the result from `config.guess/config.sub`. These files are imported from the autoconf project. Unfortunately, they have changed the license to one incompatible with OpenJDK, so we are stuck with an old version. Instead, we have created a "bugfix wrapper" that calls the original `autoconf-config.guess/sub` and fixes up the result, with stuff like this.

make/autoconf/platform.m4 line 273:

> 271:   # Convert the autoconf OS/CPU value to our own data, into the VAR_OS/CPU/LIBC variables.
> 272:   PLATFORM_EXTRACT_VARS_FROM_OS($build_os)
> 273:   PLATFORM_EXTRACT_VARS_FROM_CPU($build_cpu, $build_os)

Fixing the comment above means this change, and the one below, can be reverted.

make/common/NativeCompilation.gmk line 1180:

> 1178:                 # silently fail otherwise.
> 1179:                 ifneq ($(CODESIGN), )
> 1180: 		  $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" --timestamp --options runtime \

What does -f do, and is it needed for macos-x64 as well?

make/modules/jdk.hotspot.agent/Lib.gmk line 34:

> 32: 
> 33: else ifeq ($(call isTargetOs, macosx), true)
> 34:   SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \

Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons).

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

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

From vkempik at openjdk.java.net  Mon Jan 25 13:33:47 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 13:33:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
Message-ID: <H0K3sUe4APFRYh0HtLdrFW0q1_pFibrkvTUZlMceV_Y=.0ac40c75-c893-424a-af17-adc558dc6c17@github.com>

On Mon, 25 Jan 2021 13:18:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> make/common/NativeCompilation.gmk line 1180:
> 
>> 1178:                 # silently fail otherwise.
>> 1179:                 ifneq ($(CODESIGN), )
>> 1180: 		  $(CODESIGN) -f -s "$(MACOSX_CODESIGN_IDENTITY)" --timestamp --options runtime \
> 
> What does -f do, and is it needed for macos-x64 as well?

-f  - replace signature if it's present, if not  - just sign as usual
macos-aarch64 binaries always have adhoc signature, so need to replace it.

> make/modules/jdk.hotspot.agent/Lib.gmk line 34:
> 
>> 32: 
>> 33: else ifeq ($(call isTargetOs, macosx), true)
>> 34:   SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
> 
> Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons).

@luhenry , could you please check this comment, I think SA-agent was MS's job here.

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

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

From vkempik at openjdk.java.net  Mon Jan 25 14:09:44 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 14:09:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <Zi4wsZF2zVnOW4EcKxOP4784amzXLn0L6T7tEheZACY=.2390e0bf-e710-4347-8695-05ceb1865539@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
 <Zi4wsZF2zVnOW4EcKxOP4784amzXLn0L6T7tEheZACY=.2390e0bf-e710-4347-8695-05ceb1865539@github.com>
Message-ID: <T-ElM5TJlF0qgsvySj-SS-BnnQAfEiGCMSIF6lYmAqk=.5a977646-2862-4749-a056-1d8bf1741f5d@github.com>

On Mon, 25 Jan 2021 14:03:40 GMT, Per Liden <pliden at openjdk.org> wrote:

> In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for macos/aarch64. Is that just an oversight, or is there a reason for that?

because it does not work
processor_id has no "official docs"-friendly implementation, only a hacky one from ios world.

Also ZGC needs additional W^X work.
I believe zgc supports needs to be done in a separate commit.

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

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

From pliden at openjdk.java.net  Mon Jan 25 14:06:46 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 25 Jan 2021 14:06:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
Message-ID: <Zi4wsZF2zVnOW4EcKxOP4784amzXLn0L6T7tEheZACY=.2390e0bf-e710-4347-8695-05ceb1865539@github.com>

On Mon, 25 Jan 2021 13:23:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> Changes requested by ihse (Reviewer).

In `make/autoconf/jvm-features.m4` I notice that you haven't enabled ZGC for macos/aarch64. Is that just an oversight, or is there a reason for that?

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

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

From coleenp at openjdk.java.net  Mon Jan 25 14:39:49 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 25 Jan 2021 14:39:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
Message-ID: <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>

On Sun, 24 Jan 2021 15:32:59 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:
> 
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87:

> 85:   JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env);
> 86:   DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));;
> 87:   Thread::WXWriteFromExecSetter wx_write;

Is this on every transition to VM from Native?  Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is?

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

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

From coleenp at openjdk.java.net  Mon Jan 25 14:43:44 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 25 Jan 2021 14:43:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
Message-ID: <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>

On Sun, 24 Jan 2021 15:32:59 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:
> 
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

src/hotspot/share/runtime/thread.hpp line 915:

> 913:       verify_wx_state(WXExec);
> 914:     }
> 915:   };

Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp?

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

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

From coleenp at openjdk.java.net  Mon Jan 25 14:43:46 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 25 Jan 2021 14:43:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>
Message-ID: <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com>

On Mon, 25 Jan 2021 14:40:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/share/runtime/thread.hpp line 915:
> 
>> 913:       verify_wx_state(WXExec);
>> 914:     }
>> 915:   };
> 
> Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp?

This could be a follow-up RFE.

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

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

From akozlov at openjdk.java.net  Mon Jan 25 15:03:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 25 Jan 2021 15:03:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>
Message-ID: <gh9aHbfKHXKAG3LTBZWitlw6L7p5kxwQC-Xxiyii1Ww=.d56e467d-4135-4785-968c-766c4505eb3c@github.com>

On Mon, 25 Jan 2021 14:36:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87:
> 
>> 85:   JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env);
>> 86:   DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));;
>> 87:   Thread::WXWriteFromExecSetter wx_write;
> 
> Is this on every transition to VM from Native?  Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is?

I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here.

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

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

From burban at openjdk.java.net  Mon Jan 25 16:02:45 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 25 Jan 2021 16:02:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <H0K3sUe4APFRYh0HtLdrFW0q1_pFibrkvTUZlMceV_Y=.0ac40c75-c893-424a-af17-adc558dc6c17@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
 <H0K3sUe4APFRYh0HtLdrFW0q1_pFibrkvTUZlMceV_Y=.0ac40c75-c893-424a-af17-adc558dc6c17@github.com>
Message-ID: <IQ1xC4wgzr9t6IQyuHlZGkLgbgCpjbGCquoe6QwF6OA=.20391856-485c-4057-865b-37974b526f10@github.com>

On Mon, 25 Jan 2021 13:30:55 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> make/modules/jdk.hotspot.agent/Lib.gmk line 34:
>> 
>>> 32: 
>>> 33: else ifeq ($(call isTargetOs, macosx), true)
>>> 34:   SA_CFLAGS := -D_GNU_SOURCE -mno-omit-leaf-frame-pointer \
>> 
>> Is this really proper for macos-x64? I thought we used -Damd64 as a marker for all macos-x64 C/C++ files. (Most files get their flags from the common setup in configure, but SA is a different beast due to historical reasons).
>
> @luhenry , could you please check this comment, I think SA-agent was MS's job here.

The target is identified by the header file now:
https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41

Do you think there is any problem with this approach?

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

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

From aph at openjdk.java.net  Mon Jan 25 17:21:46 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 25 Jan 2021 17:21:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <FIAu02KPkeT8mjt2BKIcVnei38gRk3aoXWTfpIvFhos=.773b9848-15d8-45b5-9669-4df8ca65b2d0@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <FIAu02KPkeT8mjt2BKIcVnei38gRk3aoXWTfpIvFhos=.773b9848-15d8-45b5-9669-4df8ca65b2d0@github.com>
Message-ID: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com>

On Sun, 24 Jan 2021 15:50:01 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp line 86:
>> 
>>> 84: 
>>> 85:   switch (_num_int_args) {
>>> 86:   case 0:
>> 
>> I don't think you need such a large switch statement. I think this can be expressed as
>> if (num_int_args <= 6) {
>>     ldr(as_Register(num_int_args + r1.encoding()), src);
>> ... etc.
>
> I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122

This is new code, and it should not repeat the mistakes of the past. There's no need to refactor the similar existing code as part of this patch.

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

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

From prr at openjdk.java.net  Mon Jan 25 17:45:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 17:45:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
Message-ID: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>

On Sun, 24 Jan 2021 15:32:59 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:
> 
>  - Address feedback for signature generators
>  - Enable -Wformat-nonliteral back

Changes requested by prr (Reviewer).

src/java.desktop/share/native/libharfbuzz/hb-common.h line 113:

> 111: 
> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF)))
> 113: #define HB_UNTAG(tag)   (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF)

I need a robust explanation of these changes.
They are not mentioned, nor are they in upstream harfbuzz.
Likely these should be pushed to upstream first if there is a reason for them.

src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 193:

> 191:    * crbug.com/549610 */
> 192:   // 0x00070000 stands for "kCTVersionNumber10_10", see CoreText.h
> 193: #if TARGET_OS_OSX && MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_10

I need a robust explanation of these changes.
They are not mentioned, nor are they in upstream harfbuzz.
Likely these should be pushed to upstream first if there is a reason for them.

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

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

From akozlov at openjdk.java.net  Mon Jan 25 17:45:47 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 25 Jan 2021 17:45:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <UKJs_0siqUqR9HgIbFpiReb_i9ASyFf8Uwo1rS9ETbM=.495a5d37-0069-4c63-8487-d64f0d14d5b2@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <UubbyJKBR24lG2v3vsTotl7bRFQrHWypAM58MRRy5Tc=.15f12745-172c-401e-8966-2e5b7137b9fc@github.com>
 <UKJs_0siqUqR9HgIbFpiReb_i9ASyFf8Uwo1rS9ETbM=.495a5d37-0069-4c63-8487-d64f0d14d5b2@github.com>
Message-ID: <rXdOvnIMi32PllNC5mylqYzbQOBSuozgxFGX2eR2i8o=.e8f4e098-d253-431d-b708-1bf410b777ce@github.com>

On Mon, 25 Jan 2021 09:52:00 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hello
>> Why is it not nice ?
>> linux_aarch64 uses some linux specific tls function _ZN10JavaThread25aarch64_get_thread_helperEv from hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.s
>> which clobbers only r0 and r1
>> macos_aarch64 has no such tls code and uses generic C-call to Thread::current();
>> Hence we  are saving possibly clobbered regs here.
>
> Surely if you did as Linux does you wouldn't need to clobber all those registers.

I see how this can be done, from looking at C example with `__thread`, which involves 
poorly documented relocations and private libc interface invocation.

But now I also wonder how much benefit would we have from this optimization.
`get_thread` is called from few places and all of them are guarded by `#ifdef ASSERT`. The release build is still fine after I removed MacroAssembler::get_thread definition (as a verification).

Callers of get_thread:
* StubAssembler::call_RT
* Runtime1::generate_patching
* StubGenerator::generate_call_stub
* StubGenerator::generate_catch_exception

All of them are heavy-weight functions, nonoptimal get_thread is unlikely to slow them down even in fastdebug.

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

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

From coleenp at openjdk.java.net  Mon Jan 25 19:14:48 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 25 Jan 2021 19:14:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <gh9aHbfKHXKAG3LTBZWitlw6L7p5kxwQC-Xxiyii1Ww=.d56e467d-4135-4785-968c-766c4505eb3c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>
 <gh9aHbfKHXKAG3LTBZWitlw6L7p5kxwQC-Xxiyii1Ww=.d56e467d-4135-4785-968c-766c4505eb3c@github.com>
Message-ID: <jXnEmEqfBhFsYuuaQSFX09N2_0SdvH05rEhstHxEtIU=.87837f33-2ddc-4667-84db-b2134a916069@github.com>

On Mon, 25 Jan 2021 15:01:25 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87:
>> 
>>> 85:   JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env);
>>> 86:   DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));;
>>> 87:   Thread::WXWriteFromExecSetter wx_write;
>> 
>> Is this on every transition to VM from Native?  Would it be better to add to ThreadInVMfromNative like the ResetNoHandleMark is?
>
> I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here.

Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like:
class ThreadInVMfromNative : public ThreadStateTransition {
  ResetNoHandleMark __rnhm;

We can look at it with cleaning up the thread transitions RFE or as a follow-on.  If every line of ThreadInVMfromNative has to have one of these   Thread::WXWriteVerifier __wx_write;     people are going to miss them when adding the former.

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

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

From akozlov at openjdk.java.net  Mon Jan 25 19:38:16 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 25 Jan 2021 19:38:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
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: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@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 two additional commits since the last revision:

 - Refactor CDS disabling
 - Redo builsys support for aarch64-darwin

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/50b55f66..0c2cb0a3

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

  Stats: 36 lines in 3 files changed: 12 ins; 15 del; 9 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 Jan 25 20:50:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 20:50:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>

On Mon, 25 Jan 2021 19:38:16 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:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:

> 571:     EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
> 572:     WARNINGS_AS_ERRORS_xlc := false, \
> 573:     DISABLED_WARNINGS_clang := deprecated-declarations, \

I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things.
I've built JDK using Xcode 12.3 and not had any need for this.

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

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

From vkempik at openjdk.java.net  Mon Jan 25 21:21:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 21:21:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
Message-ID: <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>

On Mon, 25 Jan 2021 20:54:38 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
>> 
>>> 571:     EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>>> 572:     WARNINGS_AS_ERRORS_xlc := false, \
>>> 573:     DISABLED_WARNINGS_clang := deprecated-declarations, \
>> 
>> I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things.
>> I've built JDK using Xcode 12.3 and not had any need for this.
>
> Hello
> I believe it was a workaround for issues with xcode 12.2 in early beta days.
> Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds.

It seems these workarounds are still needed:

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations]
                        bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat
                                      ^~~~~~~~~~~~~~~~~~~~~~~~
                                      NSBitmapFormatAlphaFirst

jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations]
                      styleMask: NSBorderlessWindowMask
                                 ^~~~~~~~~~~~~~~~~~~~~~
                                 NSWindowStyleMaskBorderless

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

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

From vkempik at openjdk.java.net  Mon Jan 25 21:21:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 21:21:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
Message-ID: <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>

On Mon, 25 Jan 2021 19:42:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 573:
> 
>> 571:     EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \
>> 572:     WARNINGS_AS_ERRORS_xlc := false, \
>> 573:     DISABLED_WARNINGS_clang := deprecated-declarations, \
> 
> I see this added here and in another location. What is deprecated ? You really need to explain these sorts of things.
> I've built JDK using Xcode 12.3 and not had any need for this.

Hello
I believe it was a workaround for issues with xcode 12.2 in early beta days.
Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds.

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

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

From prr at openjdk.java.net  Mon Jan 25 22:24:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 22:24:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
Message-ID: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>

On Mon, 25 Jan 2021 21:18:59 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Hello
>> I believe it was a workaround for issues with xcode 12.2 in early beta days.
>> Those issues were fixed later in upstream jdk, so most likely we need to remove these workarounds.
>
> It seems these workarounds are still needed:
> 
> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations]
>                         bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat
>                                       ^~~~~~~~~~~~~~~~~~~~~~~~
>                                       NSBitmapFormatAlphaFirst
> 
> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations]
>                       styleMask: NSBorderlessWindowMask
>                                  ^~~~~~~~~~~~~~~~~~~~~~
>                                  NSWindowStyleMaskBorderless

Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem.
I think we currently target a macOS 10.9 and if you are changing that it would need discussion.
If you are changing it only for Mac ARM that may make more sense .. 

And these appear to be just API churn by Apple
NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst

https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc

NSBorderlessWindowMask is replaced by NSWindowStyleMask

https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ

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

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

From vkempik at openjdk.java.net  Mon Jan 25 22:28:46 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 22:28:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
Message-ID: <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>

On Mon, 25 Jan 2021 22:22:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> It seems these workarounds are still needed:
>> 
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:300:39: error: 'NSAlphaFirstBitmapFormat' is deprecated: first deprecated in macOS 10.14 [-Werror,-Wdeprecated-declarations]
>>                         bitmapFormat: NSAlphaFirstBitmapFormat | NSAlphaNonpremultipliedBitmapFormat
>>                                       ^~~~~~~~~~~~~~~~~~~~~~~~
>>                                       NSBitmapFormatAlphaFirst
>> 
>> jdk/src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m:438:34: error: 'NSBorderlessWindowMask' is deprecated: first deprecated in macOS 10.12 [-Werror,-Wdeprecated-declarations]
>>                       styleMask: NSBorderlessWindowMask
>>                                  ^~~~~~~~~~~~~~~~~~~~~~
>>                                  NSWindowStyleMaskBorderless
>
> Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem.
> I think we currently target a macOS 10.9 and if you are changing that it would need discussion.
> If you are changing it only for Mac ARM that may make more sense .. 
> 
> And these appear to be just API churn by Apple
> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst
> 
> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc
> 
> NSBorderlessWindowMask is replaced by NSWindowStyleMask
> 
> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ

Min_macos version is changed to 11.0 for macos_aarch64

https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136

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

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

From prr at openjdk.java.net  Mon Jan 25 22:45:42 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 22:45:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
Message-ID: <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>

On Mon, 25 Jan 2021 22:25:48 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Are you doing something somewhere to change the target version of macOS or SDK ? I had no such problem.
>> I think we currently target a macOS 10.9 and if you are changing that it would need discussion.
>> If you are changing it only for Mac ARM that may make more sense .. 
>> 
>> And these appear to be just API churn by Apple
>> NSAlphaFirstBitmapFormat is replaced by NSBitmapFormatAlphaFirst
>> 
>> https://developer.apple.com/documentation/appkit/nsbitmapformat/nsbitmapformatalphafirst?language=objc
>> 
>> NSBorderlessWindowMask is replaced by NSWindowStyleMask
>> 
>> https://developer.apple.com/documentation/appkit/nswindowstylemask?language=occ
>
> Min_macos version is changed to 11.0 for macos_aarch64
> 
> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136

1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
2) So maybe rather than the deprecation suppression  you could change both constants to the new ones.
Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ...

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

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

From vkempik at openjdk.java.net  Mon Jan 25 22:50:44 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Mon, 25 Jan 2021 22:50:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
 <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
Message-ID: <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>

On Mon, 25 Jan 2021 22:42:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> Min_macos version is changed to 11.0 for macos_aarch64
>> 
>> https://github.com/openjdk/jdk/pull/2200/files/0c2cb0a372bf1a8607810d773b53d6959616a816#diff-7cd97cdbeb3053597e5d6659016cdf0f60b2c412bd39934a43817ee0b717b7a7R136
>
> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
> 2) So maybe rather than the deprecation suppression  you could change both constants to the new ones.
> Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ...

that sounds good to me, I am just afraid to break intel mac on older macos versions with this change.

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

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

From cjplummer at openjdk.java.net  Mon Jan 25 23:01:47 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 25 Jan 2021 23:01:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <rdKaZHN6LY1Q-gyUsnoyyVo1v_aNHC2FA9o2fnHV7p4=.22083b03-2e46-4ebf-80d0-08ca351a26d7@github.com>

On Mon, 25 Jan 2021 19:38:16 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:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

I looked through the SA changes. Overall looks good except for a couple of minor issues noted. For the most part it seems to have been boilerplate copy-n-paste from existing ports. If there is anything you want me to take a closer look at, let me know.

src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m line 702:

> 700:   primitiveArray = (*env)->GetLongArrayElements(env, registerArray, NULL);
> 701: 
> 702: #undef REG_INDEX

I'm not so sure why the #undef and subsequent #define of REG_INDEX is needed since it seems to just get #define'd back to the same value.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64ThreadContext.java line 2:

> 1: /*
> 2:  * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved.

Update copyright.

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

Marked as reviewed by cjplummer (Reviewer).

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

From cjplummer at openjdk.java.net  Mon Jan 25 23:08:48 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 25 Jan 2021 23:08:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <0a4qdfSXm3tmLgOW3MJoTc8VSL4XGnaKXrSEbaeL3h0=.d7c6ce7f-183f-429c-8b3e-7f6bc3379f23@github.com>

On Mon, 25 Jan 2021 19:38:16 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:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

JDI changes also look good.

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

Marked as reviewed by cjplummer (Reviewer).

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

From prr at openjdk.java.net  Mon Jan 25 23:38:44 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 23:38:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <tPYHeoCfwsWBUwwbzR-qCHaBALbNGepSA5oFyAPonLU=.3933e6d3-0e0c-40c5-80a8-f5d1d88cc6e7@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
 <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
 <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>
 <tPYHeoCfwsWBUwwbzR-qCHaBALbNGepSA5oFyAPonLU=.3933e6d3-0e0c-40c5-80a8-f5d1d88cc6e7@github.com>
Message-ID: <WfEqLKuao1Rb3IbgKVhOvdZY-_SQ8bfEmV-kxjm207Y=.b8ff8e15-9379-41d7-9562-fcd84ac34d7e@github.com>

On Mon, 25 Jan 2021 23:34:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> that sounds good to me, I am just afraid to break intel mac on older macos versions with this change.
>
> That may actually be a valid concern. Both say macOS 10.12+ ...  which might conflict with the 10.9 target.

Maybe you should just file a bug after all for this to be dealt with separately.
Certainly if it is NOT fixed now such a bug needs to be filed.

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

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

From prr at openjdk.java.net  Mon Jan 25 23:38:43 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 25 Jan 2021 23:38:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
 <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
 <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>
Message-ID: <tPYHeoCfwsWBUwwbzR-qCHaBALbNGepSA5oFyAPonLU=.3933e6d3-0e0c-40c5-80a8-f5d1d88cc6e7@github.com>

On Mon, 25 Jan 2021 22:47:33 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> 1) I meant change to NSWindowStyleMaskBorderless from NSBorderlessWindowMask
>> 2) So maybe rather than the deprecation suppression  you could change both constants to the new ones.
>> Ordinarily I'd say let someone else do that but this looks like a simple obvious change and is dwarfed by all the other changes going on for Mac ARM ...
>
> that sounds good to me, I am just afraid to break intel mac on older macos versions with this change.

That may actually be a valid concern. Both say macOS 10.12+ ...  which might conflict with the 10.9 target.

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

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

From serb at openjdk.java.net  Tue Jan 26 01:56:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Jan 2021 01:56:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables
 with CSS
In-Reply-To: <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
Message-ID: <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>

On Mon, 25 Jan 2021 11:50:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
>> table {border: outset 1px}
>> th, td {border: inset 1px} 
>> 
>> These declarations produce the same rendering as the default one in Firefox and Edge. 
>> 
>> Another option is to use `solid` in both cases.
>
> @jonathan-gibbons, what do you think?

Probably we can import the CSS used by the javadoc itself?

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

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

From vkempik at openjdk.java.net  Tue Jan 26 07:26:43 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 07:26:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <WfEqLKuao1Rb3IbgKVhOvdZY-_SQ8bfEmV-kxjm207Y=.b8ff8e15-9379-41d7-9562-fcd84ac34d7e@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <cqwt3jDc9IP0Jq_93eI0SR0ghtISP-x9AucrjqfyVGQ=.5716366b-6dfb-4bc5-b92e-3b91ec5ab0cf@github.com>
 <gj_wnThKIfmIY913pDF9UfWDmaEaM5zpeuGnzpflCFs=.c647f0d9-f5c7-45ff-ba62-15887a071b81@github.com>
 <adeGQ-2g5gzY-ktzTBvkCmImwYyZ9s2J5qvb_mX82wA=.46778120-7b11-4448-b90f-27d6f3cc033a@github.com>
 <_zD5tEXjb79l9Myc4XNePJtnyO9DuoPiLxC-INoRUvQ=.008fbe51-1485-41b7-a844-41c13114a12b@github.com>
 <lUUs89xMKCesBvqrcHR1ARJ4tkAapLf3zsw8Q6Xzy8w=.8805912e-8a45-4a45-9855-e3842cbb7d36@github.com>
 <aCR3VA-Er-eu7C0InGW42leiGLCMFPq9mWsRdxptH0I=.a7a82ee7-398f-488d-a68b-92922b9ca550@github.com>
 <CG49GDIyQ-LhJSqmQlYJkA6vuaPtbZu0BViteNL3FlE=.23a19350-6984-4d4f-b1bd-1fc6d7d3fc4a@github.com>
 <tPYHeoCfwsWBUwwbzR-qCHaBALbNGepSA5oFyAPonLU=.3933e6d3-0e0c-40c5-80a8-f5d1d88cc6e7@github.com>
 <WfEqLKuao1Rb3IbgKVhOvdZY-_SQ8bfEmV-
 kxjm207Y=.b8ff8e15-9379-41d7-9562-fcd84ac34d7e@github.com>
Message-ID: <suhKbL5tx6LK-OYunNUVrwm8sQ9p5pnIlf4R8St_6fY=.95827835-840f-4611-b913-88c1a4591dc7@github.com>

On Mon, 25 Jan 2021 23:35:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> That may actually be a valid concern. Both say macOS 10.12+ ...  which might conflict with the 10.9 target.
>
> Maybe you should just file a bug after all for this to be dealt with separately.
> Certainly if it is NOT fixed now such a bug needs to be filed.

I have created https://bugs.openjdk.java.net/browse/JDK-8260402 which is blocked by jep-391 currently

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

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

From stefank at openjdk.java.net  Tue Jan 26 08:57:54 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 26 Jan 2021 08:57:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <LPIrDcPyBUiYSxhlNElZv49wesHgigBXIRjiQ0npkFY=.32795c2b-2d9f-4fb5-9a35-b7b7d4e7fa49@github.com>

On Mon, 25 Jan 2021 19:38:16 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:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

>     * 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.

I wonder if this is the right choice. I think it would have been good if this could have been completely hidden in the transition classes. However, that doesn't seem to have been enough and now there are explicit Thread::WXWriteFromExecSetter instances where it's not at all obvious why they are needed. For example, why was it added here?:
OopStorageParIterPerf::~OopStorageParIterPerf() {
  // missing transition to vm state
  Thread::WXWriteFromExecSetter wx_write;
  _storage.release(_entries, ARRAY_SIZE(_entries));
}
You need to dig down in the OopStorage implementation to find that it's because it uses SafeFetch, which has the opposite transition:
inline int SafeFetch32(int* adr, int errValue) {
  assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
  Thread::WXExecFromWriteSetter wx_exec;
  return StubRoutines::SafeFetch32_stub()(adr, errValue);
}
I think this adds complexity to code that shouldn't have to deal with this. I'm fine with having to force devs / code that writes to exec memory to have to deal with a bit more complexity, but it seems wrong to let this leak out to code that is staying far away from that.

For my understanding, was this choice made because the nmethods instances (and maybe other types as well) are placed in the code cache memory segment, which is executable? If the code cache only contained the JIT:ed code, and not object instances, I think this could more easily have been contained a bit more.

If the proposed solution is going to stay, maybe this could be made a little bit nicer by changing the SafeFetch implementation to use a new scoped object that doesn't enforce the "from" state to be "write"? Instead it could check if the state is "write" and only then flip the state back and forth. I think, this would remove the change needed OopStorageParIterPerf, and probably other places as well.

src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp line 38:

> 36: #include "runtime/os.hpp"
> 37: #include "runtime/stubRoutines.hpp"
> 38: #include "runtime/stubRoutines.inline.hpp"

Remove stubRutines.hpp line

src/hotspot/share/runtime/stubRoutines.inline.hpp line 29:

> 27: 
> 28: #include <runtime/thread.hpp>
> 29: #include <runtime/stubRoutines.hpp>

Replace < > with " "

src/hotspot/os/aix/os_aix.cpp line 70:

> 68: #include "runtime/statSampler.hpp"
> 69: #include "runtime/stubRoutines.hpp"
> 70: #include "runtime/stubRoutines.inline.hpp"

Remove stubRutines.hpp line

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

Changes requested by stefank (Reviewer).

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

From ihse at openjdk.java.net  Tue Jan 26 09:25:50 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Jan 2021 09:25:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
Message-ID: <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>

On Mon, 25 Jan 2021 19:38:16 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:
> 
>  - Refactor CDS disabling
>  - Redo builsys support for aarch64-darwin

Changes requested by ihse (Reviewer).

make/autoconf/build-aux/autoconf-config.guess line 1275:

> 1273: 		      UNAME_PROCESSOR="aarch64"
> 1274: 		  fi
> 1275: 		fi ;;

Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file.

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

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

From ihse at openjdk.java.net  Tue Jan 26 10:14:41 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Jan 2021 10:14:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from
 make to respective module [v4]
In-Reply-To: <ad2uU37xBO8wpE-w6Ogj3paBihqfXiKLRJ627VwNgkc=.1d6a7573-d606-4eb1-ba21-5daaf47c485c@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>
 <YT7on7W1w9GJRTMfz2KtftKo7yGbVTgZxYcqXv1POBU=.59b49a13-da41-4c93-88c7-1830b87d0b63@github.com>
 <95Qw1lVtqPHbGHoNJo46xIPO3OEof9nqCGJ3xA-oNZ8=.fa51b0e5-b33b-4f96-9756-a46741841201@github.com>
 <ABB2Pleoo1GTfmn0SdjrztH_u6VrfPRseLfMIrYhMdg=.a576b5bc-b25b-43ee-b5d3-394bce1415ca@github.com>
 <ad2uU37xBO8wpE-w6Ogj3paBihqfXiKLRJ627VwNgkc=.1d6a7573-d606-4eb1-ba21-5daaf47c485c@github.com>
Message-ID: <aq-xpyHEodngcRGTGmPGqWJ3nsBiCmJEDWvyvjLXBxo=.fb62e3dd-ddbf-4b71-b3fb-3d93d7fdd4bf@github.com>

On Sat, 23 Jan 2021 07:55:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We should create a separate issue to rename them and get rid of the copying in the make file.

I opened https://bugs.openjdk.java.net/browse/JDK-8260406.

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

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

From akozlov at openjdk.java.net  Tue Jan 26 11:33:45 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 11:33:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>
 <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com>
Message-ID: <YPcSqODkAflJPr_fnUNlHxpGB9IQSNqMhuf_2gFq8GY=.c8ed7d36-a354-43a8-9161-9c7160e7096b@github.com>

On Mon, 25 Jan 2021 14:40:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 915:
>> 
>>> 913:       verify_wx_state(WXExec);
>>> 914:     }
>>> 915:   };
>> 
>> Rather than add all this to thread.hpp, can you make a wxVerifier.hpp and just add the class instance as a field in thread.hpp?
>
> This could be a follow-up RFE.

I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. 
* We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. 
* An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance.

If such costs are negligible, I can do as suggested.

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

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

From coleenp at openjdk.java.net  Tue Jan 26 12:04:48 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 26 Jan 2021 12:04:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <YPcSqODkAflJPr_fnUNlHxpGB9IQSNqMhuf_2gFq8GY=.c8ed7d36-a354-43a8-9161-9c7160e7096b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <51L0YGiOtGUEJUjhJkGnTRsoNofBsnSbopxjamQSesE=.0c2f3387-9f62-4d37-b2e8-73b5a5002641@github.com>
 <-_A-bf8i3jWY1awmyxwzi3yv4UoJQelRbJrMQVWQGLU=.5103b95d-3ad7-4a70-8d46-60c0eb0a301f@github.com>
 <YPcSqODkAflJPr_fnUNlHxpGB9IQSNqMhuf_2gFq8GY=.c8ed7d36-a354-43a8-9161-9c7160e7096b@github.com>
Message-ID: <OTfNjQUNPASnskM8tBLuTLhT5OrJ36rjx4RDRbyBhQo=.05a1a086-9494-4483-963a-cb41955623a5@github.com>

On Tue, 26 Jan 2021 11:31:18 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> This could be a follow-up RFE.
>
> I assume a WXVerifier class that tracks W^X mode in debug mode and does nothing in release mode. I've considered to do this, it's relates to small inefficiencies, while this patch brings zero overhead (in release) for a platform that does not need W^X. 
> * We don't need thread instance in release to call `os::current_thread_enable_wx`. Having WXVerifier a part of the Thread will require calling `Thread::current()` first and we could only hope for compiler to optimize this out, not sure if it will happen at all. In some contexts the Thread instance is available, in some it's not. 
> * An instance of the empty class (as WXVerifier will be in the release) will occupy non-zero space in the Thread instance.
> 
> If such costs are negligible, I can do as suggested.

I really just want the minimal number of lines of code and hooks in thread.hpp.  You can still access it through the thread, just like these lines currently.  Look at HandshakeState as an example.

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

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

From github.com+4146708+a74nh at openjdk.java.net  Tue Jan 26 12:04:47 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 26 Jan 2021 12:04:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
Message-ID: <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>

On Tue, 26 Jan 2021 09:23:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>
> Changes requested by ihse (Reviewer).

AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
ie:
`
--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'
`

Otherwise there will be missing _JNFNative* functions.

Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?

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

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

From vkempik at openjdk.java.net  Tue Jan 26 12:09:42 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 12:09:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
Message-ID: <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>

On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
> ie:
> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
> 
> Otherwise there will be missing _JNFNative* functions.
> 
> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?

There is ongoing work by P. Race to eliminate dependence on JNF at all

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

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

From github.com+4146708+a74nh at openjdk.java.net  Tue Jan 26 12:36:44 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Tue, 26 Jan 2021 12:36:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
Message-ID: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>

On Tue, 26 Jan 2021 12:06:28 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
> > ie:
> > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
> > Otherwise there will be missing _JNFNative* functions.
> > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
> 
> There is ongoing work by P. Race to eliminate dependence on JNF at all

Ok, that's great.
In the meantime is it worth adding something to the MacOS section of doc/building.* ?
(I pieced together the required line from multiple posts in a mailing list)

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

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

From magnus.ihse.bursie at oracle.com  Tue Jan 26 12:44:34 2021
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 26 Jan 2021 13:44:34 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
Message-ID: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com>

On 2021-01-26 13:09, Vladimir Kempik wrote:
> On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:
>
>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>> ie:
>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>
>> Otherwise there will be missing _JNFNative* functions.
>>
>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
> There is ongoing work by P. Race to eliminate dependence on JNF at all
How far has that work come? Otherwise the logic should be added to 
configure to look for this framework automatically, and provide a way to 
override it/set it if not found.

I don't think it's OK to publish a new port that cannot build 
out-of-the-box without hacks like this.

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


From akozlov at openjdk.java.net  Tue Jan 26 12:52:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 12:52:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <jXnEmEqfBhFsYuuaQSFX09N2_0SdvH05rEhstHxEtIU=.87837f33-2ddc-4667-84db-b2134a916069@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <X9wlF4x4NEgbqm4jgkh3npkup8hOt70EBr9HOk_boU0=.2850f987-a8bf-436d-9a8f-f3588f18f0f7@github.com>
 <gh9aHbfKHXKAG3LTBZWitlw6L7p5kxwQC-Xxiyii1Ww=.d56e467d-4135-4785-968c-766c4505eb3c@github.com>
 <jXnEmEqfBhFsYuuaQSFX09N2_0SdvH05rEhstHxEtIU=.87837f33-2ddc-4667-84db-b2134a916069@github.com>
Message-ID: <LAHF4QAE1MzvoQElpyRW5K_MnNdA3asNRceSXclodHw=.b2b705e3-a073-4597-8293-b2f25fdca37f@github.com>

On Mon, 25 Jan 2021 19:12:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I've tried to do something like this initially. The idea was to use Write in VM state and Exec in Java and Native states. However, for example, JIT runs in the Native state and needs Write access. So instead, W^X is managed on entry and exit from VM code, in macros like JRT_ENTRY. Unfortunately, not every JVM entry function is defined with an appropriate macro (at least for now), so I had to add explicit W^X state management along with the explicit java thread state, like here.
>
> Yes, that's why I thought it should be added to the classes ThreadInVMfromNative, etc like:
> class ThreadInVMfromNative : public ThreadStateTransition {
>   ResetNoHandleMark __rnhm;
> 
> We can look at it with cleaning up the thread transitions RFE or as a follow-on.  If every line of ThreadInVMfromNative has to have one of these   Thread::WXWriteVerifier __wx_write;     people are going to miss them when adding the former.

Not every ThreadInVMfromNative needs this, for example JIT goes to Native state without changing of W^X state. But from some experience of maintaining this patch, I actually had a duty to add missing W^X transitions after assert failures. A possible solution is actually to make W^X transition a part of ThreadInVMfromNative (and similar), but controlled by an optional constructor parameter with possible values "do exec->write", "verify write"...;. So in a common case ThreadInVMfromNative would implicitly do the transition and still would allow something uncommon like verification of the state for the JIT. I have to think about this.

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

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

From akozlov at openjdk.java.net  Tue Jan 26 15:06:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 15:06:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v4]
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: <XYWWD_-xDBcyFTTPPpMp1ZFg6yTMYHekN6gGIchvl6Q=.089fc86a-cdda-4c8e-9da5-c0aa5bf45b44@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:

 - Little adjustement of SlowSignatureHandler
 - Partially bring previous commit
 - Revert "Address feedback for signature generators"
   
   This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/0c2cb0a3..fef36580

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

  Stats: 98 lines in 1 file changed: 74 ins; 13 del; 11 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 Jan 26 15:06:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 15:06:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v4]
In-Reply-To: <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <FIAu02KPkeT8mjt2BKIcVnei38gRk3aoXWTfpIvFhos=.773b9848-15d8-45b5-9669-4df8ca65b2d0@github.com>
 <0WPkx3i-N0HHqCqrxE_B0Rf2akunbQaWQb7M7Z88BQY=.c582d11a-ba8d-4789-a55b-279e1286ad8d@github.com>
Message-ID: <yrOiRGUo0yNwPkJP1jmyylqNEOqZwbRcwSs5aWi_eKc=.5a1f3d0f-b71a-4af8-8708-9299d188f8aa@github.com>

On Mon, 25 Jan 2021 10:00:20 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I like the suggestion. For the defense, new functions were made this way intentionally, to match existing `pass_int`, `pass_long`,.. I take your comment as a blessing to fix all of them. But I feel that refactoring of existing code should go in a separate commit. Especially after `pass_int` used `ldr/str` instead of `ldrw/strw`, which looks wrong. https://github.com/openjdk/jdk/pull/2200/files#diff-1ff58ce70aeea7e9842d34e8d8fd9c94dd91182999d455618b2a171efd8f742cL87-R122
>
> This is new code, and it should not repeat the mistakes of the past. There's no need to refactor the similar existing code as part of this patch.

Makes sense, I've reverted changes in the old code but will propose them in the separate PR shortly.

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

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

From aivanov at openjdk.java.net  Tue Jan 26 15:42:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 15:42:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables
 with CSS
In-Reply-To: <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
 <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
Message-ID: <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>

On Tue, 26 Jan 2021 01:54:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably we can import the CSS used by the javadoc itself?

We do. For example, [AWT Modality in JDK 15](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html) has borders because of `border="1"` attribute. If you remove it or change it to `border="1"` in Developer Tools in browser, the borders around cells disappear.

However, I looked into it further: there are tables in Javadoc comments. One example is [AWTKeyStroke constructor](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/AWTKeyStroke.html#%3Cinit%3E()) which uses `class="striped"`. In most cases, classes in java.desktop module use striped tables.

There's also `plain` class. I've found one usage of `class=plain"` in [NumericShaper class](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/font/NumericShaper.html). This style has collapsed borders around each cell. It looks similar to what we have now in ?plain? HTML documents, yet by default the borders are not collapsed, that is you see borders around each individual cell.

The stylesheet also declares `borderless` class which has no borders.

For the consistent look and feel of documentation, I think `striped` is the most appropriate class. However, I prefer `plain` class for `componentProperties.html` file.

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

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

From vkempik at openjdk.java.net  Tue Jan 26 16:09:50 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 16:09:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
Message-ID: <lm6_fD7AG2u5_qnZvcgUhV3sE7lOkhY4VHNthCcRUMo=.fbfa3181-7a8e-4c17-9407-70b41a750333@github.com>

On Mon, 25 Jan 2021 17:43:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/java.desktop/share/native/libharfbuzz/hb-common.h line 113:
> 
>> 111: 
>> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF)))
>> 113: #define HB_UNTAG(tag)   (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF)
> 
> I need a robust explanation of these changes.
> They are not mentioned, nor are they in upstream harfbuzz.
> Likely these should be pushed to upstream first if there is a reason for them.

@lewurm This and other harfbuzz changes came from MS, could you please comment here ?

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

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

From burban at openjdk.java.net  Tue Jan 26 16:38:47 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Tue, 26 Jan 2021 16:38:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <lm6_fD7AG2u5_qnZvcgUhV3sE7lOkhY4VHNthCcRUMo=.fbfa3181-7a8e-4c17-9407-70b41a750333@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
 <lm6_fD7AG2u5_qnZvcgUhV3sE7lOkhY4VHNthCcRUMo=.fbfa3181-7a8e-4c17-9407-70b41a750333@github.com>
Message-ID: <JM00RWcui-aHK-ytznCeMD_RrUopPTgXMVYspuK4SU0=.11098349-bc01-424f-a2d5-79265689e021@github.com>

On Tue, 26 Jan 2021 16:07:19 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/java.desktop/share/native/libharfbuzz/hb-common.h line 113:
>> 
>>> 111: 
>>> 112: #define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint32_t)(c1)&0xFF)<<24)|(((uint32_t)(c2)&0xFF)<<16)|(((uint32_t)(c3)&0xFF)<<8)|((uint32_t)(c4)&0xFF)))
>>> 113: #define HB_UNTAG(tag)   (char)(((tag)>>24)&0xFF), (char)(((tag)>>16)&0xFF), (char)(((tag)>>8)&0xFF), (char)((tag)&0xFF)
>> 
>> I need a robust explanation of these changes.
>> They are not mentioned, nor are they in upstream harfbuzz.
>> Likely these should be pushed to upstream first if there is a reason for them.
>
> @lewurm This and other harfbuzz changes came from MS, could you please comment here ?

This looks like a merge fix mistake: https://github.com/openjdk/jdk/commit/051357ef977ecab77fa9b2b1e61f94f288e716f9#diff-e3815f37244d076e27feef0c778fb78a4e5691b47db9c92abcb28bb2a9c2865e

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

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

From aivanov at openjdk.java.net  Tue Jan 26 17:26:56 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 17:26:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables
 with CSS [v2]
In-Reply-To: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
Message-ID: <IYM4buU_FjWSDBpUrojgyEL7N6qV1NbxswKLu87B8xw=.a32211d6-fb92-4e10-bbb9-e7b8315fd890@github.com>

> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
> table {border: outset 1px}
> th, td {border: inset 1px} 
> 
> These declarations produce the same rendering as the default one in Firefox and Edge. 
> 
> Another option is to use `solid` in both cases.

Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:

 - Remove redundant center-align for <tr> element
 - Apply class="striped" to the tables

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2210/files
  - new: https://git.openjdk.java.net/jdk/pull/2210/files/eb057764..b6f95ed8

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

  Stats: 59 lines in 6 files changed: 0 ins; 24 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2210/head:pull/2210

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

From aivanov at openjdk.java.net  Tue Jan 26 17:32:54 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 17:32:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables
 with CSS [v3]
In-Reply-To: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
Message-ID: <jFvdBcb-LwcRK3b82mXIogE4tleQqKjdMhNqzVYcCVw=.b66a66a1-8cf6-4911-9353-1362f43e1509@github.com>

> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
> table {border: outset 1px}
> th, td {border: inset 1px} 
> 
> These declarations produce the same rendering as the default one in Firefox and Edge. 
> 
> Another option is to use `solid` in both cases.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to style block in componentProperties.html

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2210/files
  - new: https://git.openjdk.java.net/jdk/pull/2210/files/b6f95ed8..9a7d1315

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

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

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

From aivanov at openjdk.java.net  Tue Jan 26 18:36:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 18:36:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables
 with CSS
In-Reply-To: <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
 <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
 <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>
Message-ID: <-a9q9HZa8vBMJc_T0Th_Q-rw2H-gm_sNj-Wz8s7hjsc=.c8791127-4eeb-40f7-b7f0-ad07b6af97ee@github.com>

On Tue, 26 Jan 2021 15:39:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Probably we can import the CSS used by the javadoc itself?
>
>> Probably we can import the CSS used by the javadoc itself?
> 
> We do. For example, [AWT Modality in JDK 15](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html) has borders because of `border="1"` attribute. If you remove it or change it to `border="1"` in Developer Tools in browser, the borders around cells disappear.
> 
> However, I looked into it further: there are tables in Javadoc comments. One example is [AWTKeyStroke constructor](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/AWTKeyStroke.html#%3Cinit%3E()) which uses `class="striped"`. In most cases, classes in java.desktop module use striped tables.
> 
> There's also `plain` class. I've found one usage of `class=plain"` in [NumericShaper class](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/font/NumericShaper.html). This style has collapsed borders around each cell. It looks similar to what we have now in ?plain? HTML documents, yet by default the borders are not collapsed, that is you see borders around each individual cell.
> 
> The stylesheet also declares `borderless` class which has no borders.
> 
> For the consistent look and feel of documentation, I think `striped` is the most appropriate class. However, I prefer `plain` class for `componentProperties.html` file.

I updated all the tables with `class="striped"`.

I've also uploaded the files with different styles for visual comparison:

### Current: JDK 15

- [DesktopProperties.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
- [Modality.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html)
- [gif_metadata.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
- [tiff_metadata.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
- [componentProperties.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
- [synthFileFormat.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)

### Manual: as suggested initially

- [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
- [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/java/awt/doc-files/Modality.html)
- [gif_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
- [tiff_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
- [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
- [synthFileFormat.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)

### Striped: `class="striped"`

- [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
- [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/java/awt/doc-files/Modality.html)
- [gif_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
- [tiff_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
- [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
- [synthFileFormat.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)

### Plain: `class="plain"`

- [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
- [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/java/awt/doc-files/Modality.html)
- [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)

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

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

From akozlov at openjdk.java.net  Tue Jan 26 18:42:02 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 18:42:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v5]
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: <gPhGkmWJHK8x-AKI-M3tQAHU9UvkU6FWbzmVuc-j__k=.12e5dcc4-aa00-4099-934f-a23128cdf41c@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:

  Revert harfbuzz changes, disable warnings for it

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/fef36580..b2b396fc

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

  Stats: 5 lines in 3 files changed: 1 ins; 2 del; 2 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 erik.joelsson at oracle.com  Tue Jan 26 18:42:49 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 26 Jan 2021 10:42:49 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
 <0ce3d16d-76e1-dd38-1b13-d693bc490915@oracle.com>
Message-ID: <58df0666-2c69-a4dd-3bb8-fd00c859b490@oracle.com>


On 2021-01-26 04:44, Magnus Ihse Bursie wrote:
> On 2021-01-26 13:09, Vladimir Kempik wrote:
>> On Tue, 26 Jan 2021 12:02:02 GMT, Alan Hayward 
>> <github.com+4146708+a74nh at openjdk.org> wrote:
>>
>>> AIUI, the configure line needs passing a prebuilt 
>>> JavaNativeFoundation framework
>>> ie:
>>> `--with-extra-ldflags='-F 
>>> /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>>
>>> Otherwise there will be missing _JNFNative* functions.
>>>
>>> Is this the long term plan? Or will eventually the required code be 
>>> moved into JDK and/or the xcode one automatically get picked up by 
>>> the configure scripts?
>> There is ongoing work by P. Race to eliminate dependence on JNF at all
> How far has that work come? Otherwise the logic should be added to 
> configure to look for this framework automatically, and provide a way 
> to override it/set it if not found.
>
> I don't think it's OK to publish a new port that cannot build 
> out-of-the-box without hacks like this.
>
My understanding is that Apple chose to not provide JNF for aarch64, so 
if you want to build OpenJDK, you first need to build JNF yourself (it's 
available in github). Phil is working on removing this dependency 
completely, which will solve this issue [1].

In the meantime, I don't think we should rely on finding JNF in 
unsupported locations inside Xcode. Could we wait with integrating this 
port until it can be built without such hacks? If not, then adding 
something in the documentation on how to get a working JNF would at 
least be needed.

/Erik

[1] https://bugs.openjdk.java.net/browse/JDK-8257852

From akozlov at openjdk.java.net  Tue Jan 26 18:54:46 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 18:54:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <JM00RWcui-aHK-ytznCeMD_RrUopPTgXMVYspuK4SU0=.11098349-bc01-424f-a2d5-79265689e021@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
 <lm6_fD7AG2u5_qnZvcgUhV3sE7lOkhY4VHNthCcRUMo=.fbfa3181-7a8e-4c17-9407-70b41a750333@github.com>
 <JM00RWcui-aHK-ytznCeMD_RrUopPTgXMVYspuK4SU0=.11098349-bc01-424f-a2d5-79265689e021@github.com>
Message-ID: <w7gwBf0UyQDfwKv7o8VxdnTOMrb6O03paC15dcq3mj0=.360a880d-e452-4f5d-8b63-687fee1ecc0a@github.com>

On Tue, 26 Jan 2021 16:35:54 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> @lewurm This and other harfbuzz changes came from MS, could you please comment here ?
>
> This looks like a merge fix mistake: https://github.com/openjdk/jdk/commit/051357ef977ecab77fa9b2b1e61f94f288e716f9#diff-e3815f37244d076e27feef0c778fb78a4e5691b47db9c92abcb28bb2a9c2865e

I've reverted this change and disabled some warnings for libharfbuzz instead. I should be blamed, yes. Now this is consistent with other changes covered by JDK-8260402

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

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

From philip.race at oracle.com  Tue Jan 26 18:58:27 2021
From: philip.race at oracle.com (Philip Race)
Date: Tue, 26 Jan 2021 10:58:27 -0800
Subject: [OpenJDK 2D-Dev] Project Lanai (New Metal Java 2D Rendering
 pipeline for macOS) FINAL planned EA build has been released
Message-ID: <129fc386-0ca1-52ce-5378-8303b32d5fea@oracle.com>

All,

The Lanai project has reached the stage where we are aiming to move the 
JEP [1]
to Proposed-To-Target [2] to JDK 17 very soon.

We have made one final planned EA release which includes all the latest 
fixes.

So please visit https://jdk.java.net/lanai/ and download the EA 9 build 
and 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://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html



From philip.race at oracle.com  Tue Jan 26 19:05:15 2021
From: philip.race at oracle.com (Philip Race)
Date: Tue, 26 Jan 2021 11:05:15 -0800
Subject: [OpenJDK 2D-Dev] Project Lanai (New Metal Java 2D Rendering
 pipeline for macOS) FINAL planned EA build has been released
Message-ID: <ef6ce471-1b0e-acb0-8a7d-95a8be82a278@oracle.com>

All,

The Lanai project has reached the stage where we are aiming to move the 
JEP [1]
to Proposed-To-Target [2] to JDK 17 very soon.

We have made one final planned EA release which includes all the latest 
fixes.

So please visit https://jdk.java.net/lanai/ and download the EA 9 build 
and 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://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html


From jjg at openjdk.java.net  Tue Jan 26 19:19:39 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 26 Jan 2021 19:19:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables
 with CSS
In-Reply-To: <-a9q9HZa8vBMJc_T0Th_Q-rw2H-gm_sNj-Wz8s7hjsc=.c8791127-4eeb-40f7-b7f0-ad07b6af97ee@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
 <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
 <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>
 <-a9q9HZa8vBMJc_T0Th_Q-rw2H-gm_sNj-Wz8s7hjsc=.c8791127-4eeb-40f7-b7f0-ad07b6af97ee@github.com>
Message-ID: <8iEqmKYzPqc_Y1A5rBHkR7_4rrFy-G__ruCFxIvFhf4=.116926f8-e276-4429-8c51-35aadfa017ae@github.com>

On Tue, 26 Jan 2021 18:33:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Probably we can import the CSS used by the javadoc itself?
>> 
>> We do. For example, [AWT Modality in JDK 15](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html) has borders because of `border="1"` attribute. If you remove it or change it to `border="1"` in Developer Tools in browser, the borders around cells disappear.
>> 
>> However, I looked into it further: there are tables in Javadoc comments. One example is [AWTKeyStroke constructor](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/AWTKeyStroke.html#%3Cinit%3E()) which uses `class="striped"`. In most cases, classes in java.desktop module use striped tables.
>> 
>> There's also `plain` class. I've found one usage of `class=plain"` in [NumericShaper class](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/font/NumericShaper.html). This style has collapsed borders around each cell. It looks similar to what we have now in ?plain? HTML documents, yet by default the borders are not collapsed, that is you see borders around each individual cell.
>> 
>> The stylesheet also declares `borderless` class which has no borders.
>> 
>> For the consistent look and feel of documentation, I think `striped` is the most appropriate class. However, I prefer `plain` class for `componentProperties.html` file.
>
> I updated all the tables with `class="striped"`.
> 
> I've also uploaded the files with different styles for visual comparison:
> 
> ### Current: JDK 15
> 
> - [DesktopProperties.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
> - [Modality.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/java/awt/doc-files/Modality.html)
> - [gif_metadata.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
> - [tiff_metadata.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
> - [componentProperties.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
> - [synthFileFormat.html](https://docs.oracle.com/en/java/javase/15/docs/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)
> 
> ### Manual: as suggested initially
> 
> - [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
> - [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/java/awt/doc-files/Modality.html)
> - [gif_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
> - [tiff_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
> - [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
> - [synthFileFormat.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v1-manual/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)
> 
> ### Striped: `class="striped"`
> 
> - [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
> - [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/java/awt/doc-files/Modality.html)
> - [gif_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/imageio/metadata/doc-files/gif_metadata.html)
> - [tiff_metadata.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/imageio/metadata/doc-files/tiff_metadata.html)
> - [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)
> - [synthFileFormat.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v2-striped/api/java.desktop/javax/swing/plaf/synth/doc-files/synthFileFormat.html)
> 
> ### Plain: `class="plain"`
> 
> - [DesktopProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/java/awt/doc-files/DesktopProperties.html)
> - [Modality.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/java/awt/doc-files/Modality.html)
> - [componentProperties.html](http://cr.openjdk.java.net/~aivanov/8260314/borders/v3-plain/api/java.desktop/javax/swing/plaf/synth/doc-files/componentProperties.html)

In general, I recommend where possible using the styles provided in the standard stylesheet, for overall visual consistency.

FYI, although it seems like the standard styles work for you in this case, if you should ever need it, javadoc now supports package-specific and module-specific stylesheets. Just put `*.css` files in the `doc-files` subdirectory or a package or module, and javadoc should pick it up and use it.

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

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

From weijun at openjdk.java.net  Tue Jan 26 19:36:50 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 26 Jan 2021 19:36:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v5]
In-Reply-To: <gPhGkmWJHK8x-AKI-M3tQAHU9UvkU6FWbzmVuc-j__k=.12e5dcc4-aa00-4099-934f-a23128cdf41c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <gPhGkmWJHK8x-AKI-M3tQAHU9UvkU6FWbzmVuc-j__k=.12e5dcc4-aa00-4099-934f-a23128cdf41c@github.com>
Message-ID: <U4n2FxioAOMTtN3q40S5qmtBypJRATRHFWbynqyFI7U=.37557c2f-1c10-4f12-88cd-7058f0bb97d2@github.com>

On Tue, 26 Jan 2021 18:42:02 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:
> 
>   Revert harfbuzz changes, disable warnings for it

src/java.security.jgss/share/native/libj2gss/gssapi.h line 48:

> 46: // Condition was copied from
> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
> 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__))

So for macOS/AArch64, this `if` is no longer true?

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

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

From burban at openjdk.java.net  Tue Jan 26 19:41:50 2021
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Tue, 26 Jan 2021 19:41:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v2]
In-Reply-To: <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <_9cCI1TAyVuOtqANAZGLOlQZzSCImsKRjib4-O4z-cQ=.45edea17-90bf-496c-8110-a69bb6a34710@github.com>
Message-ID: <yfXs-k0GMczJKtfJ96FRVLLl9U5K2qJpCRni571FCoU=.328206a8-8ed3-4cb8-940a-a9f3e718cf20@github.com>

On Mon, 25 Jan 2021 17:43:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address feedback for signature generators
>>  - Enable -Wformat-nonliteral back
>
> src/java.desktop/share/native/libharfbuzz/hb-coretext.cc line 193:
> 
>> 191:    * crbug.com/549610 */
>> 192:   // 0x00070000 stands for "kCTVersionNumber10_10", see CoreText.h
>> 193: #if TARGET_OS_OSX && MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_10
> 
> I need a robust explanation of these changes.
> They are not mentioned, nor are they in upstream harfbuzz.
> Likely these should be pushed to upstream first if there is a reason for them.

I'm afraid it's one of those dirty changes that we did to make progress, but forgot to revisit later. Without the guard you would get:
* For target support_native_java.desktop_libharfbuzz_hb-coretext.o:

  if (&CTGetCoreTextVersion != nullptr && CTGetCoreTextVersion() < 0x00070000) {
       ^

uint32_t CTGetCoreTextVersion( void ) CT_DEPRECATED("Use -[NSProcessInfo operatingSystemVersion]", macos(10.5, 11.0), ios(3.2, 14.0), watchos(2.0, 7.0), tvos(9.0, 14.0));
         ^

  if (&CTGetCoreTextVersion != nullptr && CTGetCoreTextVersion() < 0x00070000) {
                                          ^

uint32_t CTGetCoreTextVersion( void ) CT_DEPRECATED("Use -[NSProcessInfo operatingSystemVersion]", macos(10.5, 11.0), ios(3.2, 14.0), watchos(2.0, 7.0), tvos(9.0, 14.0));
         ^
2 errors generated.
For now, it's probably better to go with what Anton did in the latest commit https://github.com/openjdk/jdk/pull/2200/commits/b2b396fca679fbc7ee78fb5bc80191bc79e1c490
Eventually upstream will do something about it I assume? How often does it get synced with upstream? Maybe worth to file an issue.

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

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

From aivanov at openjdk.java.net  Tue Jan 26 19:42:39 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 26 Jan 2021 19:42:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables
 with CSS
In-Reply-To: <8iEqmKYzPqc_Y1A5rBHkR7_4rrFy-G__ruCFxIvFhf4=.116926f8-e276-4429-8c51-35aadfa017ae@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <YKhi4Zzu38p92cIBzy68kH9JZCRxNPvYE7yHshV-V5o=.91b1d2d6-b53e-4ae0-9c33-16fa1f8afc88@github.com>
 <aUTDefEe39WcMRteFMcjWsCBxrZoLmKcBB08UdN9YH8=.ec6f9042-e386-47e3-8153-600e4ed5c3e9@github.com>
 <Trl0CXTObhupISF-aQFAmoUV6ARx_4ErgpfjPk2Fzq8=.a40a4a8f-a8e6-4996-bd71-b014d1aed178@github.com>
 <-a9q9HZa8vBMJc_T0Th_Q-rw2H-gm_sNj-Wz8s7hjsc=.c8791127-4eeb-40f7-b7f0-ad07b6af97ee@github.com>
 <8iEqmKYzPqc_Y1A5rBHkR7_4rrFy-G__ruCFxIvFhf4=.116926f8-e276-4429-8c51-35aadfa017ae@github.com>
Message-ID: <Jqo-_zfXyaISQ4mIiJVNW6d8AVx7Oiu4RcARjESLA88=.b9ef5259-6e63-4da7-8fbf-f4665021fe56@github.com>

On Tue, 26 Jan 2021 19:17:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> In general, I recommend where possible using the styles provided in the standard stylesheet, for overall visual consistency.

I totally agree.  I overlooked the standard styles for the tables. Thanks to @mrserb for pointing me in the right direction.

Since most tables in java.desktop use striped tables, it makes sense to use this style in these files too.

Although I had said I preferred `plain` class for `componentProperties.html`, I changed my opinion after looking at the updated file, it feels lighter when striped.

The table in `NumericShaper` has confusing rendering with `striped` class, that's why it uses `plain`.

> FYI, although it seems like the standard styles work for you in this case, if you should ever need it, javadoc now supports package-specific and module-specific stylesheets. Just put `*.css` files in the `doc-files` subdirectory or a package or module, and javadoc should pick it up and use it.

Thank you. It's good to know as it allows for keeping consistent look across files as opposed to applying style changes in individual files.

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

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

From vkempik at openjdk.java.net  Tue Jan 26 20:02:50 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 20:02:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v5]
In-Reply-To: <U4n2FxioAOMTtN3q40S5qmtBypJRATRHFWbynqyFI7U=.37557c2f-1c10-4f12-88cd-7058f0bb97d2@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <gPhGkmWJHK8x-AKI-M3tQAHU9UvkU6FWbzmVuc-j__k=.12e5dcc4-aa00-4099-934f-a23128cdf41c@github.com>
 <U4n2FxioAOMTtN3q40S5qmtBypJRATRHFWbynqyFI7U=.37557c2f-1c10-4f12-88cd-7058f0bb97d2@github.com>
Message-ID: <gQHutmDlViAyVjtcm2IaOKZ6kbKMoYQhGhPXbwSpEPo=.59f467de-01ed-4f25-9438-40cab26d50b2@github.com>

On Tue, 26 Jan 2021 19:33:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert harfbuzz changes, disable warnings for it
>
> src/java.security.jgss/share/native/libj2gss/gssapi.h line 48:
> 
>> 46: // Condition was copied from
>> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
>> 48: #if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__))
> 
> So for macOS/AArch64, this `if` is no longer true?

That is according to Xcode sdk.

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

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

From serb at openjdk.java.net  Tue Jan 26 20:20:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Jan 2021 20:20:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException
In-Reply-To: <X5XnJic4tyYKEUQjJ_SuJMUjaGB_cEYEKJX4uCwuVh0=.dc9f5550-dd79-4272-a4d2-a02282a22d8b@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
 <X5XnJic4tyYKEUQjJ_SuJMUjaGB_cEYEKJX4uCwuVh0=.dc9f5550-dd79-4272-a4d2-a02282a22d8b@github.com>
Message-ID: <xyES1NiR43To_FH5wfSuiiOaV5QrDC1GAtlEHz8OsjI=.4743c56a-99ea-416f-80da-86525943e00c@github.com>

On Sun, 3 Jan 2021 03:14:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
>> 
>> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
>> 
>> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
>> 
>> Notes about the link above:
>> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
>> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
>> 
>> The fix:
>>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
>> 
>> See some comments inline.
>
> Any volunteers for a review?

Any volunteers for a review?

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

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

From serb at openjdk.java.net  Tue Jan 26 20:20:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Jan 2021 20:20:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6606673: Path2D.Double,
 Path2D.Float and GeneralPath ctors throw exception when
 initialCapacity is negative
In-Reply-To: <UlLqutLFc5YneTz7oZYmHsNamYBU1yMDRZZxaY_zkNs=.19d6a8ed-e547-4636-8788-ed4aa6063f3a@github.com>
References: <jfDwXHyb_Hyb2REogHuRLy0WM91GMLPvNujaorXWH2Y=.7f7dbd30-78d5-46eb-81b3-d32455fc0631@github.com>
 <UlLqutLFc5YneTz7oZYmHsNamYBU1yMDRZZxaY_zkNs=.19d6a8ed-e547-4636-8788-ed4aa6063f3a@github.com>
Message-ID: <cnP0JM5J8yszdaSNaRigvVsEZNuNHQkc-VZxQmCHGcc=.d4424070-3c4f-44ab-ad6d-b2132f8f7af5@github.com>

On Thu, 21 Jan 2021 05:09:35 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> The specification for Path2D.Double, Path2D.Float and GeneralPath constructors is updated. NegativeArraySizeException, IllegalArgumentException and NullPointerException are added.
>
> Marked as reviewed by kizune (Reviewer).

Can somebody take a look at the CSR? https://bugs.openjdk.java.net/browse/JDK-8260192

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

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

From serb at openjdk.java.net  Tue Jan 26 20:44:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 26 Jan 2021 20:44:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260314: Replace border="1" on tables
 with CSS [v3]
In-Reply-To: <jFvdBcb-LwcRK3b82mXIogE4tleQqKjdMhNqzVYcCVw=.b66a66a1-8cf6-4911-9353-1362f43e1509@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
 <jFvdBcb-LwcRK3b82mXIogE4tleQqKjdMhNqzVYcCVw=.b66a66a1-8cf6-4911-9353-1362f43e1509@github.com>
Message-ID: <YPpf5B9mPYkcqG-seo__zQm1vRk6PChZpmD2-5BnVt8=.e4e4908f-aaa6-4d74-b4f1-6133020ba8e8@github.com>

On Tue, 26 Jan 2021 17:32:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
>> table {border: outset 1px}
>> th, td {border: inset 1px} 
>> 
>> These declarations produce the same rendering as the default one in Firefox and Edge. 
>> 
>> Another option is to use `solid` in both cases.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to style block in componentProperties.html

Marked as reviewed by serb (Reviewer).

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

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

From akozlov at openjdk.java.net  Tue Jan 26 21:59:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 26 Jan 2021 21:59:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v6]
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: <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@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:

  Redo buildsys fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/b2b396fc..f1ef6240

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

  Stats: 18 lines in 2 files changed: 8 ins; 10 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 vkempik at openjdk.java.net  Tue Jan 26 22:07:48 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 26 Jan 2021 22:07:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
Message-ID: <ovN1AB7FTV92iIOLhFzcn8zJb0m02eoVDY5JVgQ6IW8=.faed2b97-2fbe-42f0-8aa9-b6b7eabc1326@github.com>

On Tue, 26 Jan 2021 09:23:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor CDS disabling
>>  - Redo builsys support for aarch64-darwin
>
> make/autoconf/build-aux/autoconf-config.guess line 1275:
> 
>> 1273: 		      UNAME_PROCESSOR="aarch64"
>> 1274: 		  fi
>> 1275: 		fi ;;
> 
> Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file.

Hello
I have updated PR and moved this logic to make/autoconf/build-aux/config.guess
It's pretty similar to i386 -> x86_64 fix-up on macos_intel

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

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

From serb at openjdk.java.net  Wed Jan 27 02:55:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 27 Jan 2021 02:55:44 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 6606673: Path2D.Double,
 Path2D.Float and GeneralPath ctors throw exception when
 initialCapacity is negative
In-Reply-To: <jfDwXHyb_Hyb2REogHuRLy0WM91GMLPvNujaorXWH2Y=.7f7dbd30-78d5-46eb-81b3-d32455fc0631@github.com>
References: <jfDwXHyb_Hyb2REogHuRLy0WM91GMLPvNujaorXWH2Y=.7f7dbd30-78d5-46eb-81b3-d32455fc0631@github.com>
Message-ID: <rbsfQ5F3lgEU_BQTlbFZDmXQri9l9jFmsMtZzzsNPWI=.c2ea06cf-f4a5-4bb7-84c7-2847c9d8f7ab@github.com>

On Thu, 21 Jan 2021 00:50:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The specification for Path2D.Double, Path2D.Float and GeneralPath constructors is updated. NegativeArraySizeException, IllegalArgumentException and NullPointerException are added.

This pull request has now been integrated.

Changeset: e1411fd4
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e1411fd4
Stats:     218 lines in 4 files changed: 218 ins; 0 del; 0 mod

6606673: Path2D.Double, Path2D.Float and GeneralPath ctors throw exception when initialCapacity is negative

Reviewed-by: psadhukhan, kizune

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

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

From dholmes at openjdk.java.net  Wed Jan 27 06:50:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 27 Jan 2021 06:50:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
 <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>
Message-ID: <Txu8OUN7kV33jxLsGHrwYJRV2fwE0wPaYEM2B4PjwHA=.ca204c57-7ffb-4540-b397-c1d805b16481@github.com>

On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>>> ie:
>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>> 
>>> Otherwise there will be missing _JNFNative* functions.
>>> 
>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
>> 
>> There is ongoing work by P. Race to eliminate dependence on JNF at all
>
>> > AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>> > ie:
>> > `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>> > Otherwise there will be missing _JNFNative* functions.
>> > Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
>> 
>> There is ongoing work by P. Race to eliminate dependence on JNF at all
> 
> Ok, that's great.
> In the meantime is it worth adding something to the MacOS section of doc/building.* ?
> (I pieced together the required line from multiple posts in a mailing list)

Hi Anton,

Just to add weight to comments already made by @coleenp and @stefank , I also find the W^X coding support to be too intrusive and polluting of the shared code. I would much rather see this support pushed down as far as possible, to minimise the impact and to use ifdef'd code for macos/Aarch64 (via MACOS_AARCH64_ONLY macro) rather than providing empty methods.

Thanks,
David

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

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

From ihse at openjdk.java.net  Wed Jan 27 08:29:45 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 27 Jan 2021 08:29:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v6]
In-Reply-To: <IQ1xC4wgzr9t6IQyuHlZGkLgbgCpjbGCquoe6QwF6OA=.20391856-485c-4057-865b-37974b526f10@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <2wn66gOh0ezQssR63oCL82zCvBkga3mRlycGNbCtUqE=.e1c58219-93a0-47d2-8358-80a78f16d513@github.com>
 <DbmqwFNrfBhdBMARLx4fbTam5Nqjb4nHDfDX9ePhSdw=.1969f025-2b9c-4d36-957c-2ba4718a2fbb@github.com>
 <H0K3sUe4APFRYh0HtLdrFW0q1_pFibrkvTUZlMceV_Y=.0ac40c75-c893-424a-af17-adc558dc6c17@github.com>
 <IQ1xC4wgzr9t6IQyuHlZGkLgbgCpjbGCquoe6QwF6OA=.20391856-485c-4057-865b-37974b526f10@github.com>
Message-ID: <l19MEW6eFCLdUx8xhNrTnlSNGlfNglpFAa4NmB7KnVg=.f2c5a11d-7001-49a2-aaa5-36caf0445894@github.com>

On Mon, 25 Jan 2021 16:00:23 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> @luhenry , could you please check this comment, I think SA-agent was MS's job here.
>
> The target is identified by the header file now:
> https://github.com/openjdk/jdk/pull/2200/files#diff-51442e74eeef2163f0f0643df0ae995083f666367e25fba2b527a9a5bc8743a6R35-R41
> 
> Do you think there is any problem with this approach?

@lewurm No, that's okay. I just wanted to know that this had not been lost.

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

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

From ihse at openjdk.java.net  Wed Jan 27 08:32:46 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 27 Jan 2021 08:32:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <ovN1AB7FTV92iIOLhFzcn8zJb0m02eoVDY5JVgQ6IW8=.faed2b97-2fbe-42f0-8aa9-b6b7eabc1326@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <ovN1AB7FTV92iIOLhFzcn8zJb0m02eoVDY5JVgQ6IW8=.faed2b97-2fbe-42f0-8aa9-b6b7eabc1326@github.com>
Message-ID: <RMVoZHdrp_odKyra8FySso-UsmmIaJ2H3DGS2YvzWMo=.6bf4c5f2-c173-4d1f-8e70-f72124eee46f@github.com>

On Tue, 26 Jan 2021 22:04:48 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> make/autoconf/build-aux/autoconf-config.guess line 1275:
>> 
>>> 1273: 		      UNAME_PROCESSOR="aarch64"
>>> 1274: 		  fi
>>> 1275: 		fi ;;
>> 
>> Almost, but not quite, correct. We cannot change the autoconf-config.guess file due to license restrictions (the license allows redistribution, not modifications). Instead we have the config.guess file which "wraps" autoconf-config.guess and makes pre-/post-call modifications to work around limitations in the autoconf original file. So you need to check there if you are getting incorrect results back and adjust it in that case. See the already existing clauses in that file.
>
> Hello
> I have updated PR and moved this logic to make/autoconf/build-aux/config.guess
> It's pretty similar to i386 -> x86_64 fix-up on macos_intel

Thanks. That looks better.

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

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

From ihse at openjdk.java.net  Wed Jan 27 08:38:46 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 27 Jan 2021 08:38:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v6]
In-Reply-To: <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
Message-ID: <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>

On Tue, 26 Jan 2021 21:59:03 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:
> 
>   Redo buildsys fix

Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR.

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

Marked as reviewed by ihse (Reviewer).

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

From david.holmes at oracle.com  Wed Jan 27 08:42:53 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 27 Jan 2021 18:42:53 +1000
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <Txu8OUN7kV33jxLsGHrwYJRV2fwE0wPaYEM2B4PjwHA=.ca204c57-7ffb-4540-b397-c1d805b16481@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
 <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>
 <Txu8OUN7kV33jxLsGHrwYJRV2fwE0wPaYEM2B4PjwHA=.ca204c57-7ffb-4540-b397-c1d805b16481@github.com>
Message-ID: <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com>

I don't know why the Skara tools decided to associate my comment with 
Alan Hayward's comment as they are not at all related. :(

David

On 27/01/2021 4:50 pm, David Holmes wrote:
> On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:
> 
>>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>>>> ie:
>>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>>>
>>>> Otherwise there will be missing _JNFNative* functions.
>>>>
>>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
>>>
>>> There is ongoing work by P. Race to eliminate dependence on JNF at all
>>
>>>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation framework
>>>> ie:
>>>> `--with-extra-ldflags='-F /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/Frameworks/'`
>>>> Otherwise there will be missing _JNFNative* functions.
>>>> Is this the long term plan? Or will eventually the required code be moved into JDK and/or the xcode one automatically get picked up by the configure scripts?
>>>
>>> There is ongoing work by P. Race to eliminate dependence on JNF at all
>>
>> Ok, that's great.
>> In the meantime is it worth adding something to the MacOS section of doc/building.* ?
>> (I pieced together the required line from multiple posts in a mailing list)
> 
> Hi Anton,
> 
> Just to add weight to comments already made by @coleenp and @stefank , I also find the W^X coding support to be too intrusive and polluting of the shared code. I would much rather see this support pushed down as far as possible, to minimise the impact and to use ifdef'd code for macos/Aarch64 (via MACOS_AARCH64_ONLY macro) rather than providing empty methods.
> 
> Thanks,
> David
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2200
> 

From mbaesken at openjdk.java.net  Wed Jan 27 08:44:54 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 27 Jan 2021 08:44:54 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory
Message-ID: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>

The function  AllocateSpaceForGP in freetypeScaler.c calls potentially 2 times malloc ; however the memory is not always freed correctly in case of errors.
See also the related  sonar issue :
https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&resolved=false&severities=BLOCKER&types=BUG

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

Commit messages:
 - JDK-8260432

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

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

From aph at redhat.com  Wed Jan 27 09:43:36 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 27 Jan 2021 09:43:36 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v3]
In-Reply-To: <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <jfepsNqfNE9TSizS98ltKa_H47jkQiDJlgfLZdF01mk=.064ad260-417b-495b-bc28-4017d570a4dc@github.com>
 <p3cqaqHFurpbuNJoVjGFarWPpgjoHO33rp3gXiIcIkc=.ef1a8cd3-b597-44f2-8033-a44f4ab7688d@github.com>
 <RVUqncN8BLrGU1Rxdrg1zk_yE-sSQsZ08fge6Jp9ijI=.c355f1e9-1b9f-4e11-9243-c44b557b447d@github.com>
 <AE1YSbX-p_TaPh63xDXrPiDSfWhU6Ve4fDxg5KPrFSc=.7a3c8269-7238-4928-af00-00c3e13e76c6@github.com>
 <5n9zRTs8D3vp3QU8I7JxtR-Ly-yJKqUb_2NFZRf488Q=.f49c6b0f-6768-4e4a-87ec-fe46a7cf287b@github.com>
 <Txu8OUN7kV33jxLsGHrwYJRV2fwE0wPaYEM2B4PjwHA=.ca204c57-7ffb-4540-b397-c1d805b16481@github.com>
 <2f9e8ea2-a3a9-53d0-f735-894272a3717e@oracle.com>
Message-ID: <90fd9651-f954-42da-1282-bf9a7de63e13@redhat.com>

On 1/26/21 6:42 PM, erik.joelsson at oracle.com wrote:
> My understanding is that Apple chose to not provide JNF for aarch64, so
> if you want to build OpenJDK, you first need to build JNF yourself (it's
> available in github). Phil is working on removing this dependency
> completely, which will solve this issue [1].
>
> In the meantime, I don't think we should rely on finding JNF in
> unsupported locations inside Xcode. Could we wait with integrating this
> port until it can be built without such hacks?

That sounds right to me.

In the meantime, there is some cleanup work to be done in mainline
on slow_signature_handler, which will potentially make the AArch64
back end merge much simpler.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From shade at openjdk.java.net  Wed Jan 27 11:45:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 27 Jan 2021 11:45:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory
In-Reply-To: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
Message-ID: <m3IsubTKQEWNsTBO2OyKlFFrlznZnxXyaOSVubAw6dc=.fb631d9a-535b-4dc5-b9c5-4faa2066467a@github.com>

On Wed, 27 Jan 2021 08:39:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The function  AllocateSpaceForGP in freetypeScaler.c calls potentially 2 times malloc ; however the memory is not always freed correctly in case of errors.
> See also the related  sonar issue :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&resolved=false&severities=BLOCKER&types=BUG

Changes requested by shade (Reviewer).

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 1290:

> 1288: 
> 1289:     /* failure if any of mallocs failed */
> 1290:     if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL)

I think it would be cleaner to free the remaining allocations on the failing path:

if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL) {
   if (gpdata->pointTypes != NULL)  free(gpdata->pointTypes);
   if (gpdata->pointCoords != NULL) free(gpdata->pointCoords);
   return 0;
} else {
   return 1;
}

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

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

From shade at openjdk.java.net  Wed Jan 27 12:04:42 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 27 Jan 2021 12:04:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory
In-Reply-To: <bLvOuoJUSDPE6Tbqqp5ugJf8N37If6YbdNuRgWF18io=.224c7613-2eac-4d10-9ba5-d315e6f5864b@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
 <m3IsubTKQEWNsTBO2OyKlFFrlznZnxXyaOSVubAw6dc=.fb631d9a-535b-4dc5-b9c5-4faa2066467a@github.com>
 <bLvOuoJUSDPE6Tbqqp5ugJf8N37If6YbdNuRgWF18io=.224c7613-2eac-4d10-9ba5-d315e6f5864b@github.com>
Message-ID: <qdOktFJeLIE0kFBoHvcdRFnwW4OICOjoz6bWKejv8iA=.4c155e5e-5eff-4a9f-ac2b-9823b407a7b6@github.com>

On Wed, 27 Jan 2021 11:59:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 1290:
>> 
>>> 1288: 
>>> 1289:     /* failure if any of mallocs failed */
>>> 1290:     if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL)
>> 
>> I think it would be cleaner to free the remaining allocations on the failing path:
>> 
>> if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL) {
>>    if (gpdata->pointTypes != NULL)  free(gpdata->pointTypes);
>>    if (gpdata->pointCoords != NULL) free(gpdata->pointCoords);
>>    return 0;
>> } else {
>>    return 1;
>> }
>
> Then we would free   as well  for the realloc code path
>     } else {
>         /* do we have enough space? */
>     ...
>     }
> Is this okay?

Yes, I think that is better: `realloc` can fail as well, and we don't want to leak those?

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

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

From mbaesken at openjdk.java.net  Wed Jan 27 12:04:42 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 27 Jan 2021 12:04:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory
In-Reply-To: <m3IsubTKQEWNsTBO2OyKlFFrlznZnxXyaOSVubAw6dc=.fb631d9a-535b-4dc5-b9c5-4faa2066467a@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
 <m3IsubTKQEWNsTBO2OyKlFFrlznZnxXyaOSVubAw6dc=.fb631d9a-535b-4dc5-b9c5-4faa2066467a@github.com>
Message-ID: <bLvOuoJUSDPE6Tbqqp5ugJf8N37If6YbdNuRgWF18io=.224c7613-2eac-4d10-9ba5-d315e6f5864b@github.com>

On Wed, 27 Jan 2021 11:41:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The function  AllocateSpaceForGP in freetypeScaler.c calls potentially 2 times malloc ; however the memory is not always freed correctly in case of errors.
>> See also the related  sonar issue :
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&resolved=false&severities=BLOCKER&types=BUG
>
> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 1290:
> 
>> 1288: 
>> 1289:     /* failure if any of mallocs failed */
>> 1290:     if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL)
> 
> I think it would be cleaner to free the remaining allocations on the failing path:
> 
> if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL) {
>    if (gpdata->pointTypes != NULL)  free(gpdata->pointTypes);
>    if (gpdata->pointCoords != NULL) free(gpdata->pointCoords);
>    return 0;
> } else {
>    return 1;
> }

Then we would free   as well  for the realloc code path
    } else {
        /* do we have enough space? */
    ...
    }
Is this okay?

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

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

From aivanov at openjdk.java.net  Wed Jan 27 12:12:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 27 Jan 2021 12:12:42 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8260314: Replace border="1" on tables
 with CSS
In-Reply-To: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
References: <6Eozf9W0lwh5FChjqvq21kTq4ewQPRn24Ad0gLTbyyM=.c6f845d9-d3a3-4266-b907-029aa8eee61a@github.com>
Message-ID: <7RcNV3W7jLLvISTygnpyRzuUXDr6ZoCw6pJf_Ywz-dg=.a80267b0-0333-4d91-a88d-f4b1660f8b64@github.com>

On Sat, 23 Jan 2021 19:06:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replace presentational attribute `border="1"` on `<table>` element with CSS styles:
> table {border: outset 1px}
> th, td {border: inset 1px} 
> 
> These declarations produce the same rendering as the default one in Firefox and Edge. 
> 
> Another option is to use `solid` in both cases.

This pull request has now been integrated.

Changeset: 7ed591cc
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7ed591cc
Stats:     36 lines in 6 files changed: 0 ins; 1 del; 35 mod

8260314: Replace border="1" on tables with CSS

Reviewed-by: serb

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

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

From stuefe at openjdk.java.net  Wed Jan 27 12:19:41 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 27 Jan 2021 12:19:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory
In-Reply-To: <qdOktFJeLIE0kFBoHvcdRFnwW4OICOjoz6bWKejv8iA=.4c155e5e-5eff-4a9f-ac2b-9823b407a7b6@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
 <m3IsubTKQEWNsTBO2OyKlFFrlznZnxXyaOSVubAw6dc=.fb631d9a-535b-4dc5-b9c5-4faa2066467a@github.com>
 <bLvOuoJUSDPE6Tbqqp5ugJf8N37If6YbdNuRgWF18io=.224c7613-2eac-4d10-9ba5-d315e6f5864b@github.com>
 <qdOktFJeLIE0kFBoHvcdRFnwW4OICOjoz6bWKejv8iA=.4c155e5e-5eff-4a9f-ac2b-9823b407a7b6@github.com>
Message-ID: <_W-cRBF4-JAQE9nirdcC-zMVld60KuZ7DYJ41ms5oJY=.fc7168ad-6bd7-49ba-8e3d-354e9609b8ac@github.com>

On Wed, 27 Jan 2021 12:02:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Then we would free   as well  for the realloc code path
>>     } else {
>>         /* do we have enough space? */
>>     ...
>>     }
>> Is this okay?
>
> Yes, I think that is better: `realloc` can fail as well, and we don't want to leak those?

Please also reset the free'd pointers to NULL in GPData* before returning.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 27 12:39:02 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Jan 2021 12:39:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v2]
In-Reply-To: <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
Message-ID: <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>

On Wed, 27 Jan 2021 12:35:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent infinite loop

src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611:

> 2609:         Sleep(100);
> 2610:     }
> 2611: 

It can cause infinite looping as the message queue to get DISPOSE events is removed so if we are not getting disposed by now, we probably will not get DISPOSE event ever causing infinite loop.
XToolkit, LWToolkit does not have this infinite loop.

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

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

From psadhukhan at openjdk.java.net  Wed Jan 27 12:39:01 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 27 Jan 2021 12:39:01 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v2]
In-Reply-To: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
Message-ID: <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>

> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Prevent infinite loop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2220/files
  - new: https://git.openjdk.java.net/jdk/pull/2220/files/3db928b1..87d371ad

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

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

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

From mbaesken at openjdk.java.net  Wed Jan 27 13:09:56 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 27 Jan 2021 13:09:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory [v2]
In-Reply-To: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
Message-ID: <YF9sYNOlDHdTzfgnVAfF-EhkDURqeRVsCg3mD8BJ-bQ=.e6c77dcd-66f5-48b9-b149-5588c7dc9cbd@github.com>

> The function  AllocateSpaceForGP in freetypeScaler.c calls potentially 2 times malloc ; however the memory is not always freed correctly in case of errors.
> See also the related  sonar issue :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&resolved=false&severities=BLOCKER&types=BUG

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

  JDK-8260426

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2250/files
  - new: https://git.openjdk.java.net/jdk/pull/2250/files/5c867221..afda19e5

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

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

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

From akozlov at openjdk.java.net  Wed Jan 27 14:50:01 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 27 Jan 2021 14:50:01 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v7]
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: <rNYdBWEDqqr_8YrP9VqCYXxL_5TIWEogUHXWC4BZynI=.1f31c19c-6547-401d-b29a-d42cab24718e@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 two additional commits since the last revision:

 - Update copyright year for BsdAARCH64ThreadContext.java
 - Fix inclusing of StubRoutines header

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/f1ef6240..9d8b07c2

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

  Stats: 5 lines in 4 files changed: 0 ins; 2 del; 3 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 vkempik at openjdk.java.net  Wed Jan 27 15:01:47 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Wed, 27 Jan 2021 15:01:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v6]
In-Reply-To: <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <PMUYint7pX2wmQ5wONMdgL7GclrxCnolwttyJC7BzTg=.ca680fa2-5b08-491f-9c1c-8253ffa2bbb4@github.com>
 <LCUqjT2-6eTqN1RVGbHJQY1XBzUNRWlwDOj-ZCXDGfI=.949076d9-4311-4e7d-a95f-e59ea8e3b5e1@github.com>
Message-ID: <A2D8hAuv2S3R1jr0w8WpqNl-JfEDkT_ZpAMpYhBG-Ao=.95043299-5f1d-4198-b5aa-a9907f43fed2@github.com>

On Wed, 27 Jan 2021 08:36:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Build changes per se now looks okay. However, I agree with Erik that unless this PR can wait for the JNF removal, at the very least the build docs needs to be updated to explain how to successfully build for this platform. (I can live with the configure command line hack, since it's temporary -- otherwise I'd have requested a new configure argument.) This can be done in this PR or a follow-up PR.

I believe it's better be done under separate PR/bugfix, so it can be completely reverted once JNF removed.

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

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

From kizune at openjdk.java.net  Wed Jan 27 18:41:44 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Jan 2021 18:41:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException [v5]
In-Reply-To: <kJIfU1JhwAlEQSmgnBMF0V8VnaCDsn3sJ1ghHu_BqJU=.f016f2c7-a7a0-420d-af0e-328d97f85322@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
 <kJIfU1JhwAlEQSmgnBMF0V8VnaCDsn3sJ1ghHu_BqJU=.f016f2c7-a7a0-420d-af0e-328d97f85322@github.com>
Message-ID: <MxQGPIcjOWW0nMHFrpOhkdjG5Jk7x7Frjur1WG_Y6_s=.1ddd1799-4dcb-4f23-9a97-998565d28940@github.com>

On Fri, 22 Jan 2021 10:35:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
>> 
>> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
>> 
>> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
>> 
>> Notes about the link above:
>> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
>> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
>> 
>> The fix:
>>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
>> 
>> See some comments inline.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Update ProfileActivationDuringPropertyAccess.java
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Delete the DeferralMgr machinery
>  - Update ICC_Profile.java
>  - Wrong spec in ProfileDeferralInfo
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/14522800...ecfc1ed8

src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java line 2:

> 1: /*
> 2:  * Copyright (c) 2007, 2020, Oracle and/or its affiliates. All rights reserved.

Review took so long that years here and in other headers of modified files needs to be updated.

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

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

From kizune at openjdk.java.net  Wed Jan 27 18:51:46 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 27 Jan 2021 18:51:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException [v5]
In-Reply-To: <kJIfU1JhwAlEQSmgnBMF0V8VnaCDsn3sJ1ghHu_BqJU=.f016f2c7-a7a0-420d-af0e-328d97f85322@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
 <kJIfU1JhwAlEQSmgnBMF0V8VnaCDsn3sJ1ghHu_BqJU=.f016f2c7-a7a0-420d-af0e-328d97f85322@github.com>
Message-ID: <bdcIp_E7VlgNgdFUYWj9KziJmlZ7vUOGoxlGwFhPbyY=.4cd158e6-7ecd-4eca-857a-c993ded1621e@github.com>

On Fri, 22 Jan 2021 10:35:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
>> 
>> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
>> 
>> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
>> 
>> Notes about the link above:
>> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
>> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
>> 
>> The fix:
>>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
>> 
>> See some comments inline.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Update ProfileActivationDuringPropertyAccess.java
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Delete the DeferralMgr machinery
>  - Update ICC_Profile.java
>  - Wrong spec in ProfileDeferralInfo
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/14522800...ecfc1ed8

test/jdk/java/awt/color/ICC_ProfileRGB/MTMatrixAccess.java line 54:

> 52:                 }
> 53:                 try {
> 54:                     rgb.getMatrix();

What should happen when this method is called on profile that is not activated yet? Should you just check that it returns the non-null array of correct size?

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

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

From erikj at openjdk.java.net  Wed Jan 27 19:28:50 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 27 Jan 2021 19:28:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260518: Change default
 -mmacosx-version-min to 10.12
Message-ID: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>

To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019).

The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap.

Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402.

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

Commit messages:
 - Bump macosx version min/max to 10.12

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

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

From tbell at openjdk.java.net  Wed Jan 27 20:21:40 2021
From: tbell at openjdk.java.net (Tim Bell)
Date: Wed, 27 Jan 2021 20:21:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260518: Change default
 -mmacosx-version-min to 10.12
In-Reply-To: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
References: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
Message-ID: <CCc7JRioWXZKh5baM0KBf1Q2NTrRbbwtJqFDjdLTww0=.db784234-2fb3-4083-be15-1518f282b4b6@github.com>

On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019).
> 
> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap.
> 
> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402.

Looks good.

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

Marked as reviewed by tbell (Reviewer).

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

From prr at openjdk.java.net  Wed Jan 27 20:46:40 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 27 Jan 2021 20:46:40 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260518: Change default
 -mmacosx-version-min to 10.12
In-Reply-To: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
References: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
Message-ID: <lgNac0BzIJWZvUuec8jzrI3k034o6u0IcHQnGjzOP2k=.8e55fe2c-0236-4203-aa22-c29f85cb6162@github.com>

On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019).
> 
> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap.
> 
> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402.

Marked as reviewed by prr (Reviewer).

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

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

From aivanov at openjdk.java.net  Wed Jan 27 22:33:43 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 27 Jan 2021 22:33:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v2]
In-Reply-To: <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
Message-ID: <oY4NqtBD3uXqXd8KqACmktMv1dJp6244-XgTCTODdAo=.1885ce9e-588e-4d85-838f-13e27e200d2a@github.com>

On Wed, 27 Jan 2021 12:39:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Prevent infinite loop

test/jdk/javax/swing/JColorChooser/Test6827032.java line 78:

> 76:         } finally {
> 77:             if (frame != null) {
> 78:                 SwingUtilities.invokeAndWait(() -> frame.dispose());

Shall the frame be `volatile` too? It's accessed from main thread for the null-check.

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

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

From serb at openjdk.java.net  Thu Jan 28 00:43:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 00:43:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v2]
In-Reply-To: <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
Message-ID: <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>

On Wed, 27 Jan 2021 12:35:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Prevent infinite loop
>
> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611:
> 
>> 2609:         Sleep(100);
>> 2610:     }
>> 2611: 
> 
> It can cause infinite looping as the message queue to get DISPOSE events is removed so if we are not getting disposed by now, we probably will not get DISPOSE event ever causing infinite loop.
> XToolkit, LWToolkit does not have this infinite loop.

My point is that this is not a test bug, so the test should not be changed.

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

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

From serb at openjdk.java.net  Thu Jan 28 03:44:00 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 03:44:00 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException [v6]
In-Reply-To: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
Message-ID: <u955JmdinMKfGhJE8Bqbif1W7QMhNJU92V31hKUTRlk=.5b750a43-ac1b-4d14-9d8a-c1d3c1edaac1@github.com>

> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
> 
> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
> 
> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
> 
> Notes about the link above:
> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
> 
> The fix:
>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
> 
> See some comments inline.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'JDK-6986863' of https://github.com/mrserb/jdk into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - update dates
 - Update ProfileActivationDuringPropertyAccess.java
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - Merge branch 'master' into JDK-6986863
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/7030d2e0...e0e59caf

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

Changes: https://git.openjdk.java.net/jdk/pull/1613/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1613&range=05
  Stats: 520 lines in 9 files changed: 183 ins; 265 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1613/head:pull/1613

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

From serb at openjdk.java.net  Thu Jan 28 03:44:02 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 03:44:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException [v5]
In-Reply-To: <MxQGPIcjOWW0nMHFrpOhkdjG5Jk7x7Frjur1WG_Y6_s=.1ddd1799-4dcb-4f23-9a97-998565d28940@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
 <kJIfU1JhwAlEQSmgnBMF0V8VnaCDsn3sJ1ghHu_BqJU=.f016f2c7-a7a0-420d-af0e-328d97f85322@github.com>
 <MxQGPIcjOWW0nMHFrpOhkdjG5Jk7x7Frjur1WG_Y6_s=.1ddd1799-4dcb-4f23-9a97-998565d28940@github.com>
Message-ID: <qLsdhc3b1lSysfUQ-9MZiTJdfTRIrS4Pvg-r47RRAK8=.aa3ac296-6850-45a1-b184-6a8c06cdb119@github.com>

On Wed, 27 Jan 2021 18:38:27 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into JDK-6986863
>>  - Merge branch 'master' into JDK-6986863
>>  - Update ProfileActivationDuringPropertyAccess.java
>>  - Merge branch 'master' into JDK-6986863
>>  - Merge branch 'master' into JDK-6986863
>>  - Merge branch 'master' into JDK-6986863
>>  - Merge branch 'master' into JDK-6986863
>>  - Delete the DeferralMgr machinery
>>  - Update ICC_Profile.java
>>  - Wrong spec in ProfileDeferralInfo
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/14522800...ecfc1ed8
>
> src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2007, 2020, Oracle and/or its affiliates. All rights reserved.
> 
> Review took so long that years here and in other headers of modified files needs to be updated.

Fixed.

> test/jdk/java/awt/color/ICC_ProfileRGB/MTMatrixAccess.java line 54:
> 
>> 52:                 }
>> 53:                 try {
>> 54:                     rgb.getMatrix();
> 
> What should happen when this method is called on profile that is not activated yet? Should you just check that it returns the non-null array of correct size?

This method always returns the array, only an exception can prevent that.

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

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

From serb at openjdk.java.net  Thu Jan 28 03:57:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 03:57:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260518: Change default
 -mmacosx-version-min to 10.12
In-Reply-To: <lgNac0BzIJWZvUuec8jzrI3k034o6u0IcHQnGjzOP2k=.8e55fe2c-0236-4203-aa22-c29f85cb6162@github.com>
References: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
 <lgNac0BzIJWZvUuec8jzrI3k034o6u0IcHQnGjzOP2k=.8e55fe2c-0236-4203-aa22-c29f85cb6162@github.com>
Message-ID: <6gX0RaStGEsJCApMJtyVU3ytAfU7psYuvyVqUGldpp8=.441eeb48-e558-4e16-b68d-7a4b6fe707f6@github.com>

On Wed, 27 Jan 2021 20:43:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019).
>> 
>> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap.
>> 
>> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402.
>
> Marked as reviewed by prr (Reviewer).

Will this affect the minimum version of macOS which will be able to run on? don't we need a CSR(not sure)?

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

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

From psadhukhan at openjdk.java.net  Thu Jan 28 05:17:55 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Jan 2021 05:17:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
Message-ID: <zgUUjbxUyXbNB9ob84MBBP21qqdha_Y32bPLBhxR3H8=.e56376fb-0155-402c-82ed-c60804322d29@github.com>

> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test changes reverted

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2220/files
  - new: https://git.openjdk.java.net/jdk/pull/2220/files/87d371ad..6fdcc0d7

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

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

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

From serb at openjdk.java.net  Thu Jan 28 05:55:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 05:55:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
Message-ID: <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>

On Thu, 28 Jan 2021 00:41:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp line 2611:
>> 
>>> 2609:         Sleep(100);
>>> 2610:     }
>>> 2611: 
>> 
>> It can cause infinite looping as the message queue to get DISPOSE events is removed so if we are not getting disposed by now, we probably will not get DISPOSE event ever causing infinite loop.
>> XToolkit, LWToolkit does not have this infinite loop.
>
> My point is that this is not a test bug, so the test should not be changed.

Please take a look at the "AwtToolkit::Dispose()" method, on how much stuff should be done to properly shutdown the toolkit. This Dispose() method is executed immediately when we exit the message loop in the "Java_sun_awt_windows_WToolkit_eventLoop". So when the shutdown hook is executed we should have the message loop, then we call tk.QuitMessageLoop to stop it, and wait until all code in the Dispose() is executed. But since the IsDisposed() return false we for unknow reason hang, does it mean that the message loop still operates? Or we got some error during "QuitMessageLoop"?

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

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

From mbaesken at openjdk.java.net  Thu Jan 28 07:47:44 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 28 Jan 2021 07:47:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory [v2]
In-Reply-To: <_W-cRBF4-JAQE9nirdcC-zMVld60KuZ7DYJ41ms5oJY=.fc7168ad-6bd7-49ba-8e3d-354e9609b8ac@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
 <m3IsubTKQEWNsTBO2OyKlFFrlznZnxXyaOSVubAw6dc=.fb631d9a-535b-4dc5-b9c5-4faa2066467a@github.com>
 <bLvOuoJUSDPE6Tbqqp5ugJf8N37If6YbdNuRgWF18io=.224c7613-2eac-4d10-9ba5-d315e6f5864b@github.com>
 <qdOktFJeLIE0kFBoHvcdRFnwW4OICOjoz6bWKejv8iA=.4c155e5e-5eff-4a9f-ac2b-9823b407a7b6@github.com>
 <_W-cRBF4-JAQE9nirdcC-zMVld60KuZ7DYJ41ms5oJY=.fc7168ad-6bd7-49ba-8e3d-354e9609b8ac@github.com>
Message-ID: <rR-tptgTBZKKpg30gotXMIBJcwnkQOc2oAweXR2F8tE=.19c912ae-e233-4a74-921f-ddf4e1936a1a@github.com>

On Wed, 27 Jan 2021 12:16:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yes, I think that is better: `realloc` can fail as well, and we don't want to leak those?
>
> Please also reset the free'd pointers to NULL in GPData* before returning.

Hello  Thomas and Aleksey, I moved the free calls and added the NULL settings. Are you fine with the latest commit?
Thanks, Matthias

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

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

From shade at openjdk.java.net  Thu Jan 28 07:56:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 07:56:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory [v2]
In-Reply-To: <YF9sYNOlDHdTzfgnVAfF-EhkDURqeRVsCg3mD8BJ-bQ=.e6c77dcd-66f5-48b9-b149-5588c7dc9cbd@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
 <YF9sYNOlDHdTzfgnVAfF-EhkDURqeRVsCg3mD8BJ-bQ=.e6c77dcd-66f5-48b9-b149-5588c7dc9cbd@github.com>
Message-ID: <3_WuqAY-fKNBpaAd0pfWSS6G71qh_OeHF5ywphDU-Lw=.c0567c28-917c-4f24-af1e-abdd7887403f@github.com>

On Wed, 27 Jan 2021 13:09:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function  AllocateSpaceForGP in freetypeScaler.c calls potentially 2 times malloc ; however the memory is not always freed correctly in case of errors.
>> See also the related  sonar issue :
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&resolved=false&severities=BLOCKER&types=BUG
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8260426

This looks fine to me, modulo stylistic nits

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 1289:

> 1287:     /* failure if any of mallocs failed */
> 1288:     if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL) {
> 1289:         if (gpdata->pointTypes != NULL)  { free(gpdata->pointTypes); gpdata->pointTypes = NULL; }

You might want to add an extra space before `gpdata->pointTypes = NULL;` to align the statements vertically. You call.

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

Marked as reviewed by shade (Reviewer).

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

From shade at openjdk.java.net  Thu Jan 28 07:56:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 28 Jan 2021 07:56:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory [v2]
In-Reply-To: <3_WuqAY-fKNBpaAd0pfWSS6G71qh_OeHF5ywphDU-Lw=.c0567c28-917c-4f24-af1e-abdd7887403f@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
 <YF9sYNOlDHdTzfgnVAfF-EhkDURqeRVsCg3mD8BJ-bQ=.e6c77dcd-66f5-48b9-b149-5588c7dc9cbd@github.com>
 <3_WuqAY-fKNBpaAd0pfWSS6G71qh_OeHF5ywphDU-Lw=.c0567c28-917c-4f24-af1e-abdd7887403f@github.com>
Message-ID: <mcHZQUZoy74265_Q0mPj2NC5L6qwghlKSt_97augjw8=.58d8e885-363f-4766-bde4-22a660a101f4@github.com>

On Thu, 28 Jan 2021 07:53:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8260426
>
> This looks fine to me, modulo stylistic nits

Pull from master to get x86_32 GHA jobs fixed and running.

> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 1289:
> 
>> 1287:     /* failure if any of mallocs failed */
>> 1288:     if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL) {
>> 1289:         if (gpdata->pointTypes != NULL)  { free(gpdata->pointTypes); gpdata->pointTypes = NULL; }
> 
> You might want to add an extra space before `gpdata->pointTypes = NULL;` to align the statements vertically. You call.

Can we also style it consistently, like:

  if (gpdata->pointTypes != NULL)  { 
      free(gpdata->pointTypes);
      gpdata->pointTypes = NULL;
  }
  if (gpdata->pointCoords != NULL) {
      free(gpdata->pointCoords);
      gpdata->pointCoords = NULL;
  }

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

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

From mbaesken at openjdk.java.net  Thu Jan 28 08:25:03 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 28 Jan 2021 08:25:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory [v3]
In-Reply-To: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
Message-ID: <-GXfBW64NI27fR0uItaqwsGthWa4ShTXky6FpIx6Iqg=.bbf5f1ad-28a9-424a-be6d-5e5bb194332b@github.com>

> The function  AllocateSpaceForGP in freetypeScaler.c calls potentially 2 times malloc ; however the memory is not always freed correctly in case of errors.
> See also the related  sonar issue :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&resolved=false&severities=BLOCKER&types=BUG

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

  JDK-8260426

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2250/files
  - new: https://git.openjdk.java.net/jdk/pull/2250/files/afda19e5..70c3e879

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

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

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

From stuefe at openjdk.java.net  Thu Jan 28 09:14:43 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 28 Jan 2021 09:14:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory [v3]
In-Reply-To: <-GXfBW64NI27fR0uItaqwsGthWa4ShTXky6FpIx6Iqg=.bbf5f1ad-28a9-424a-be6d-5e5bb194332b@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
 <-GXfBW64NI27fR0uItaqwsGthWa4ShTXky6FpIx6Iqg=.bbf5f1ad-28a9-424a-be6d-5e5bb194332b@github.com>
Message-ID: <2OUqFxma9R3A_lxpFgsXRGpc-FuEMrTScYhaIgdJiHc=.e73c7469-56f6-4c7b-a6ae-c259a88c35d6@github.com>

On Thu, 28 Jan 2021 08:25:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The function  AllocateSpaceForGP in freetypeScaler.c calls potentially 2 times malloc ; however the memory is not always freed correctly in case of errors.
>> See also the related  sonar issue :
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&resolved=false&severities=BLOCKER&types=BUG
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8260426

Hi Matthias,

looks fine. See remark below, but that is just nitpicking, this is fine as it is.

Cheers, Thomas

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 1297:

> 1295:             gpdata->pointCoords = NULL;
> 1296:         }
> 1297:         return 0;

If you wanted, you could streamline this to:
    if (gpdata->pointTypes == NULL || gpdata->pointCoords == NULL) {
        free(gpdata->pointTypes);
        free(gpdata->pointCoords);
        gpdata->pointTypes = gpdata->pointCoords = NULL;
        return 0;	

Since free(NULL) is valid and a noop.

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

Marked as reviewed by stuefe (Reviewer).

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

From psadhukhan at openjdk.java.net  Thu Jan 28 10:01:42 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 28 Jan 2021 10:01:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
Message-ID: <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>

On Thu, 28 Jan 2021 05:53:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> My point is that this is not a test bug, so the test should not be changed.
>
> Please take a look at the "AwtToolkit::Dispose()" method, on how much stuff should be done to properly shutdown the toolkit. This Dispose() method is executed immediately when we exit the message loop in the "Java_sun_awt_windows_WToolkit_eventLoop". So when the shutdown hook is executed we should have the message loop, then we call tk.QuitMessageLoop to stop it, and wait until all code in the Dispose() is executed. But since the IsDisposed() return false we for unknow reason hang, does it mean that the message loop still operates? Or we got some error during "QuitMessageLoop"?

It seems in successful run, when the test finish 
- AwtToolkit::MessageLoop starts
- DoQuitMessageLoop is called
- AwtToolkit::QuitMessageLoop starts
- AwtToolkit::QuitMessageLoop finishes
- AwtToolkit::MessageLoop finish
- Dispose() is called, m_isDisposed sets to true
- shutdown hook isDisposed is true so no infinite loop 

During unsuccessful run,
 - AwtToolkit::MessageLoop starts
- DoQuitMessageLoop is called
- AwtToolkit::QuitMessageLoop starts
- AwtToolkit::QuitMessageLoop finishes
- AwtToolkit::MessageLoop NEVER ends so Dispose() is not called so m_isDisposed is not set to true so shutdown hook goes in infinite loop.

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

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

From aivanov at openjdk.java.net  Thu Jan 28 11:59:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 28 Jan 2021 11:59:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
Message-ID: <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>

On Thu, 28 Jan 2021 09:59:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Please take a look at the "AwtToolkit::Dispose()" method, on how much stuff should be done to properly shutdown the toolkit. This Dispose() method is executed immediately when we exit the message loop in the "Java_sun_awt_windows_WToolkit_eventLoop". So when the shutdown hook is executed we should have the message loop, then we call tk.QuitMessageLoop to stop it, and wait until all code in the Dispose() is executed. But since the IsDisposed() return false we for unknow reason hang, does it mean that the message loop still operates? Or we got some error during "QuitMessageLoop"?
>
> It seems in successful run, when the test finish 
> - AwtToolkit::MessageLoop starts
> - DoQuitMessageLoop is called
> - AwtToolkit::QuitMessageLoop starts
> - AwtToolkit::QuitMessageLoop finishes
> - AwtToolkit::MessageLoop finish
> - Dispose() is called, m_isDisposed sets to true
> - shutdown hook isDisposed is true so no infinite loop 
> 
> During unsuccessful run,
>  - AwtToolkit::MessageLoop starts
> - DoQuitMessageLoop is called
> - AwtToolkit::QuitMessageLoop starts
> - AwtToolkit::QuitMessageLoop finishes
> - AwtToolkit::MessageLoop NEVER ends so Dispose() is not called so m_isDisposed is not set to true so shutdown hook goes in infinite loop.

I was looking at the code yesterday. Could it be because of synchronisation? I mean, do we need to use native synchronisation to guarantee variable changes are seen across the threads?

Does MessageLoop not receive Quit / Null message?

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

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

From kizune at openjdk.java.net  Thu Jan 28 12:00:50 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 28 Jan 2021 12:00:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException [v6]
In-Reply-To: <u955JmdinMKfGhJE8Bqbif1W7QMhNJU92V31hKUTRlk=.5b750a43-ac1b-4d14-9d8a-c1d3c1edaac1@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
 <u955JmdinMKfGhJE8Bqbif1W7QMhNJU92V31hKUTRlk=.5b750a43-ac1b-4d14-9d8a-c1d3c1edaac1@github.com>
Message-ID: <nfjXHxW4A5DOiPGOso7rsh6uG-l50LCzctEP1-VrbKE=.220e1c31-5728-4c33-b7f3-0d4ff24ee40d@github.com>

On Thu, 28 Jan 2021 03:44:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
>> 
>> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
>> 
>> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
>> 
>> Notes about the link above:
>> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
>> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
>> 
>> The fix:
>>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
>> 
>> See some comments inline.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'JDK-6986863' of https://github.com/mrserb/jdk into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - update dates
>  - Update ProfileActivationDuringPropertyAccess.java
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - Merge branch 'master' into JDK-6986863
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/7030d2e0...e0e59caf

Marked as reviewed by kizune (Reviewer).

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

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

From aivanov at openjdk.java.net  Thu Jan 28 12:05:42 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 28 Jan 2021 12:05:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
 <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
Message-ID: <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>

On Thu, 28 Jan 2021 11:57:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It seems in successful run, when the test finish 
>> - AwtToolkit::MessageLoop starts
>> - DoQuitMessageLoop is called
>> - AwtToolkit::QuitMessageLoop starts
>> - AwtToolkit::QuitMessageLoop finishes
>> - AwtToolkit::MessageLoop finish
>> - Dispose() is called, m_isDisposed sets to true
>> - shutdown hook isDisposed is true so no infinite loop 
>> 
>> During unsuccessful run,
>>  - AwtToolkit::MessageLoop starts
>> - DoQuitMessageLoop is called
>> - AwtToolkit::QuitMessageLoop starts
>> - AwtToolkit::QuitMessageLoop finishes
>> - AwtToolkit::MessageLoop NEVER ends so Dispose() is not called so m_isDisposed is not set to true so shutdown hook goes in infinite loop.
>
> I was looking at the code yesterday. Could it be because of synchronisation? I mean, do we need to use native synchronisation to guarantee variable changes are seen across the threads?
> 
> Does MessageLoop not receive Quit / Null message?

> 
> My point is that this is not a test bug, so the test should not be changed.

The test never dispose of the frame. Why is it expected to shut down the toolkit? Shall the frame be disposed of when the main thread in the test finishes?

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

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

From ihse at openjdk.java.net  Thu Jan 28 12:12:45 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 28 Jan 2021 12:12:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260518: Change default
 -mmacosx-version-min to 10.12
In-Reply-To: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
References: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
Message-ID: <JplmpQp9nv-UdY5AI8Ksh_XrDzZ_56ensSJJcv7wrAs=.15ade255-08eb-4449-8727-34fff78bc4c7@github.com>

On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019).
> 
> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap.
> 
> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402.

Looks good to me.

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

Marked as reviewed by ihse (Reviewer).

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

From mbaesken at openjdk.java.net  Thu Jan 28 15:24:42 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 28 Jan 2021 15:24:42 GMT
Subject: [OpenJDK 2D-Dev] Integrated: JDK-8260432: allocateSpaceForGP in
 freetypeScaler.c might leak memory
In-Reply-To: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
References: <u3KZOGnNzw9_jTst11UweYNcRdi5z2Ozj_ZxnooDg8U=.37d175f6-9b2c-4d2e-85c8-dd29d294c4dd@github.com>
Message-ID: <8U26sx2XKPqduh7zXiocWzVMM_isWq6nnbBZesxwpLw=.cf433dc6-b36e-4a20-9db0-99afd18548df@github.com>

On Wed, 27 Jan 2021 08:39:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The function  AllocateSpaceForGP in freetypeScaler.c calls potentially 2 times malloc ; however the memory is not always freed correctly in case of errors.
> See also the related  sonar issue :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8B_SBBG2CXpcngxr&resolved=false&severities=BLOCKER&types=BUG

This pull request has now been integrated.

Changeset: 3aabbd72
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3aabbd72
Stats:     12 lines in 1 file changed: 8 ins; 0 del; 4 mod

8260432: allocateSpaceForGP in freetypeScaler.c might leak memory

Reviewed-by: shade, stuefe

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

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

From erikj at openjdk.java.net  Thu Jan 28 16:08:53 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 28 Jan 2021 16:08:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260518: Change default
 -mmacosx-version-min to 10.12 [v2]
In-Reply-To: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
References: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
Message-ID: <hCPhFDsYwCLh4hBnJedZpXAt0l8opO0mut013Tu04H0=.456d0c38-8b84-49cf-b86d-263e0e20003e@github.com>

> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019).
> 
> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap.
> 
> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402.

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

  Copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2268/files
  - new: https://git.openjdk.java.net/jdk/pull/2268/files/41d60207..4eb09479

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

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

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

From serb at openjdk.java.net  Thu Jan 28 17:17:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 17:17:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8260518: Change default
 -mmacosx-version-min to 10.12 [v2]
In-Reply-To: <hCPhFDsYwCLh4hBnJedZpXAt0l8opO0mut013Tu04H0=.456d0c38-8b84-49cf-b86d-263e0e20003e@github.com>
References: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
 <hCPhFDsYwCLh4hBnJedZpXAt0l8opO0mut013Tu04H0=.456d0c38-8b84-49cf-b86d-263e0e20003e@github.com>
Message-ID: <GQ3ZyOuZjgRzTPhVbiolqfnfEVvW-HsvzW0E_zhs6HY=.6a5c3e74-c03b-4a26-b0d5-448ff926173f@github.com>

On Thu, 28 Jan 2021 16:08:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019).
>> 
>> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap.
>> 
>> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year

Marked as reviewed by serb (Reviewer).

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

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

From serb at openjdk.java.net  Thu Jan 28 19:53:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Jan 2021 19:53:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
 <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
 <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>
Message-ID: <gyacujYwcYebhdSEb-sqHGwWHehe2oc1QJj4mV0187Y=.54ee682d-bd7f-4776-b59f-65c604d17488@github.com>

On Thu, 28 Jan 2021 12:02:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test never dispose of the frame. Why is it expected to shut down the toolkit? Shall the frame be disposed of when the main thread in the test finishes?

The shutdown is caused by the System.exit call while the toolkit active, so we should shut down it before the end.

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

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

From prr at openjdk.java.net  Fri Jan 29 00:34:55 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Jan 2021 00:34:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260616: Removing remaining JNF dependencies
 in the java.desktop module
Message-ID: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>

This completes the desktop module JNF removal

* remove  -framework JavaNativeFoundation from make files

* remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S

* replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString

* replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString

* replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI

* Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)

* Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.

* define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.

* Remove the single usage of JNFPerformEnvBlock

* replace JNFJavaToNSNumber in single A11Y file with local replacement

* replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement

* remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m

* misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)

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

Commit messages:
 - 8260616: Removing remaining JNF dependencies in the java.desktop module

Changes: https://git.openjdk.java.net/jdk/pull/2305/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260616
  Stats: 431 lines in 71 files changed: 196 ins; 96 del; 139 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2305.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2305/head:pull/2305

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

From psadhukhan at openjdk.java.net  Fri Jan 29 04:06:47 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Jan 2021 04:06:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <gyacujYwcYebhdSEb-sqHGwWHehe2oc1QJj4mV0187Y=.54ee682d-bd7f-4776-b59f-65c604d17488@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
 <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
 <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>
 <gyacujYwcYebhdSEb-sqHGwWHehe2oc1QJj4mV0187Y=.54ee682d-bd7f-4776-b59f-65c604d17488@github.com>
Message-ID: <VVuXv9sLyBXZHg9JSdz9QZWz5erSYaqt2jakdh_Ub3Q=.cd55b9d2-08cc-428a-96b7-4b99a86421ff@github.com>

On Thu, 28 Jan 2021 19:50:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> 
>>> My point is that this is not a test bug, so the test should not be changed.
>> 
>> The test never dispose of the frame. Why is it expected to shut down the toolkit? Shall the frame be disposed of when the main thread in the test finishes?
>
>> The test never dispose of the frame. Why is it expected to shut down the toolkit? Shall the frame be disposed of when the main thread in the test finishes?
> 
> The shutdown is caused by the System.exit call while the toolkit active, so we should shut down it before the end.

It seems "m_breakMessageLoop" is never true for unsuccessful run even though AwtToolkit::QuitMessageLoop finish execution (where m_breakMessageLoop is set to true),
so AwtToolkit::MessageLoop never ends, seems to be some timing issue.

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

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

From serb at openjdk.java.net  Fri Jan 29 06:22:44 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Jan 2021 06:22:44 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 6986863: ProfileDeferralMgr throwing
 ConcurrentModificationException
In-Reply-To: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
References: <rArXSmjcPq8Zwv-ACzi2ajuC7DdFyFmMvsyDkQH3V0I=.5f958959-997f-42e1-a13c-bcea5c922708@github.com>
Message-ID: <zW49QtcXNH5MVHO-73sz2Idepz1KE2bk9SDZ3NtMOvo=.c91b601b-5459-4ed0-9ff9-af61ed743063@github.com>

On Thu, 3 Dec 2020 23:52:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This change intended to enhance the lazy initialization of the standard color profiles concurrently by different threads.
> 
> We defer standard profiles loading because most of UI application uses a small amount of data from the profile like numComponents and colorSpaceType, and this data is known in advance. But any other profile-related activity (like a color conversion, profile data accesses, etc.) triggers profile activation when we load all profile data to the memory.
> 
> Before the fix for JDK-6793818, we defer only one sRGB color profile, see: https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa
> 
> Notes about the link above:
> - The code in the ProfileDeferralMgr, which contain the Vector of profiles for activation does not use any synchronization
> - The `activateDeferredProfile` and `activate` methods are implemented to throw `ProfileDataException`, but this exception is ignored during activation process: 
>     https://github.com/openjdk/jdk/commit/2726f2a3621dd2562d4fb660b4c3d376c65027aa#diff-0839c25a6c999452be28b431c54d5daa91364d302cfda6efa5c56421c2f2bdcbR96
> 
> The fix:
>  - Drops the usage of ProfileDeferralMgr (which contained the Vector of profiles for activation) and ProfileActivator machinery. Instead, we will have just one `ICC_Profile.activate()` method which will activate and initialize the `ICC_Profile.cmmProfile` if it is null
>  - The `activate` method implementation mimics the old behavior when the CMMException and IOException were wrapped by the ProfileDataException, and the ProfileDataException itself was ignored during activation - > so an exception will not be thrown in the method itself, but only when the null profile will be used.
> 
> See some comments inline.

This pull request has now been integrated.

Changeset: 64a150c5
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/64a150c5
Stats:     520 lines in 9 files changed: 183 ins; 265 del; 72 mod

6986863: ProfileDeferralMgr throwing ConcurrentModificationException

Reviewed-by: kizune

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

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

From ihse at openjdk.java.net  Fri Jan 29 10:56:42 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 29 Jan 2021 10:56:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260616: Removing remaining JNF
 dependencies in the java.desktop module
In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
Message-ID: <GRm4YKR-wt2uy6bKteX5R6QqVG61EUHeqkJ0X1FxZzo=.435035a5-ead9-47f6-9a74-9f7050a0ba21@github.com>

On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race <prr at openjdk.org> wrote:

> This completes the desktop module JNF removal
> 
> * remove  -framework JavaNativeFoundation from make files
> 
> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
> 
> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
> 
> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
> 
> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
> 
> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
> 
> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
> 
> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
> 
> * Remove the single usage of JNFPerformEnvBlock
> 
> * replace JNFJavaToNSNumber in single A11Y file with local replacement
> 
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
> 
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
> 
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)

I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF)

- There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis.

- In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with `configure --enable-static-build`)

- In `make/modules/java.desktop/Lib.gmk`, line 129, and `make/modules/java.desktop/lib/Awt2dLibraries.gmk`, line 866 & 094, it seems like `libosx`, `libawt_lwawt`, and `liboxui` also has JNF that needs to be removed. If these are fixed in any of the other issues for the umbrella JDK-8257852, I apologize. I could not figure that out.

- There is also a test dependency that I have seen being addressed, in `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`.

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

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

From aivanov at openjdk.java.net  Fri Jan 29 13:31:51 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 13:31:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <VVuXv9sLyBXZHg9JSdz9QZWz5erSYaqt2jakdh_Ub3Q=.cd55b9d2-08cc-428a-96b7-4b99a86421ff@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <WsIzSH4Xgqk1MIxR9obOQjDu6VUIHwWuyXCD5wKVUuw=.e174f6e8-83e9-48eb-bc4a-65ed7c296272@github.com>
 <SAuXiT6mTsmobACwj6F9j6T7-dCAqifISJtxOVhd6DQ=.9c45b782-144d-4f68-9e18-4beabf7bae90@github.com>
 <HadOE0oL2cGzuSQ_F1s7Lx_uVy9srbVKZwuU78ZBeo0=.6025e1f8-3d77-4f4d-856f-c8ebf559f6c0@github.com>
 <0bcS5tGMNFwilc6DdEXG6iGJgG9Jjqh7OcayzCaohzI=.54f0bdad-8804-43c1-a282-3949bcb1f575@github.com>
 <kMLumQiQftTjXvrvwZDG0xbDaxsmb98l36qxCAxl02M=.32d40e3d-fa1b-48d5-828b-2e10ef91b9b2@github.com>
 <DgfEpEd-E08sicKACCRf750lrijk2IahUBuABohtmnE=.0e462c8e-ef29-4b11-8967-78fbe77a7830@github.com>
 <VX-WLQqxEzFQjZTe0NSCMfFQ_PJXGn5dyXNzAnv420g=.f4dc9247-e2ef-4b9e-88e3-09ad8f1485da@github.com>
 <gyacujYwcYebhdSEb-sqHGwWHehe2oc1QJj4mV0187Y=.54ee682d-bd7f-4776-b59f-65c604d17488@github.com>
 <VVuXv9sLyBXZHg9JSdz9QZWz5erSYaqt2jakdh_Ub3Q=.cd55b9d2-08cc-428a-96b7-4b99a86421ff@github.com>
Message-ID: <pUqFjpjotb8m93AvXfPY3kzH4b6QGtSZq6UBYV98-aA=.32b2d092-23fd-4058-843b-8b6913f6c8e4@github.com>

On Fri, 29 Jan 2021 04:03:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems "m_breakMessageLoop" is never true for unsuccessful run even though AwtToolkit::QuitMessageLoop finish execution (where m_breakMessageLoop is set to true),
> so AwtToolkit::MessageLoop never ends and shutdown hook gets called where tk.isDisposed() loop start spinning. seems to be some timing issue.

Then this does look like a synchronisation problem. One thread changes the value of `m_breakMessageLoop` but another doesn't see it's changed. Should `m_breakMessageLoop` be declared as `volatile`?

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

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

From aivanov at openjdk.java.net  Fri Jan 29 13:34:45 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 13:34:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermiitent timeout with
 javax/swing JColorChooser Test [v3]
In-Reply-To: <vYPIGrTTyov0IBGu9IjlWDlxPSjgPIqhMUuJeXiPB38=.f7d16e82-defa-4cb7-b897-9b0547cc5d04@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <vYPIGrTTyov0IBGu9IjlWDlxPSjgPIqhMUuJeXiPB38=.f7d16e82-defa-4cb7-b897-9b0547cc5d04@github.com>
Message-ID: <xjl6bagLsI8M_cqsgZrVQFzUKHzn4bpYIwmZi_gV6Yg=.c5aae607-6eb7-4cd8-a095-46f0871cad72@github.com>

On Mon, 25 Jan 2021 15:09:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Yet I suggest fixing the typo in the bug synopsis: Intermiitent ? Intermittent

I've edited the JBS synopsis. Please also update the PR subject.

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

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

From erik.joelsson at oracle.com  Fri Jan 29 13:45:16 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Fri, 29 Jan 2021 05:45:16 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8260616: Removing remaining JNF
 dependencies in the java.desktop module
In-Reply-To: <GRm4YKR-wt2uy6bKteX5R6QqVG61EUHeqkJ0X1FxZzo=.435035a5-ead9-47f6-9a74-9f7050a0ba21@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <GRm4YKR-wt2uy6bKteX5R6QqVG61EUHeqkJ0X1FxZzo=.435035a5-ead9-47f6-9a74-9f7050a0ba21@github.com>
Message-ID: <99d3d648-803e-a014-92c0-50c862e5c328@oracle.com>


On 2021-01-29 02:56, Magnus Ihse Bursie wrote:
> On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race <prr at openjdk.org> wrote:
>
>> This completes the desktop module JNF removal
>>
>> * remove  -framework JavaNativeFoundation from make files
>>
>> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
>>
>> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
>>
>> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
>>
>> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
>>
>> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
>>
>> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
>>
>> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
>>
>> * Remove the single usage of JNFPerformEnvBlock
>>
>> * replace JNFJavaToNSNumber in single A11Y file with local replacement
>>
>> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
>>
>> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>>
>> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
> I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF)
>
> - There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis.
>
> - In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with `configure --enable-static-build`)

libosxsecurity is being worked on separately, see 
https://github.com/openjdk/jdk/pull/1845

That said, we may need a separate bug for build to remove the any 
lingering global stuff after each component has been fixed.

/Erik

> - In `make/modules/java.desktop/Lib.gmk`, line 129, and `make/modules/java.desktop/lib/Awt2dLibraries.gmk`, line 866 & 094, it seems like `libosx`, `libawt_lwawt`, and `liboxui` also has JNF that needs to be removed. If these are fixed in any of the other issues for the umbrella JDK-8257852, I apologize. I could not figure that out.
>
> - There is also a test dependency that I have seen being addressed, in `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2305

From erikj at openjdk.java.net  Fri Jan 29 14:24:41 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 29 Jan 2021 14:24:41 GMT
Subject: [OpenJDK 2D-Dev] Integrated: JDK-8260518: Change default
 -mmacosx-version-min to 10.12
In-Reply-To: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
References: <V0I0n18Gv3zstMRHJs09uHPPZmEb5WChwN-2n4j2LCc=.a82a5ee2-b153-47de-8dfd-be7e2ce3b1a8@github.com>
Message-ID: <jvOGjNhpABXSeJONl0ckLlkVhpGxjoQkmJuVcT1ctkQ=.0babadb2-7751-4af0-9b5e-69896489b77f@github.com>

On Wed, 27 Jan 2021 19:23:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> To guarantee backwards compatible binaries on Macos, we use the option -mmacosx-version-min. This is currently set to 10.9, which is a really ancient version. I propose we bump this to 10.12, which is still a rather conservative old version (support ended in 2019).
> 
> The driving issue for bumping this now is the aarch64 port, where building for aarch64 requires the version min to be set to 11.0. Having a large gap between the target versions becomes problematic as we hit a lot of deprecation warnings in shared code. To be able to fix these deprecation warnings, we need a smaller version gap.
> 
> Just bumping us to 10.12 triggers warnings in libsplashscreen, so I will temporarily add "deprecated-declarations" to the list of disabled warnings there until they can be fixed in JDK-8260402.

This pull request has now been integrated.

Changeset: 53f1b938
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/53f1b938
Stats:     5 lines in 3 files changed: 1 ins; 0 del; 4 mod

8260518: Change default -mmacosx-version-min to 10.12

Reviewed-by: tbell, prr, ihse, serb

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

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

From prr at openjdk.java.net  Fri Jan 29 16:41:44 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Jan 2021 16:41:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260616: Removing remaining JNF
 dependencies in the java.desktop module
In-Reply-To: <GRm4YKR-wt2uy6bKteX5R6QqVG61EUHeqkJ0X1FxZzo=.435035a5-ead9-47f6-9a74-9f7050a0ba21@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <GRm4YKR-wt2uy6bKteX5R6QqVG61EUHeqkJ0X1FxZzo=.435035a5-ead9-47f6-9a74-9f7050a0ba21@github.com>
Message-ID: <KFp7jnsr-bEaWHS8GbK1hpEGqfUGGi7KxIGv2NUqlnw=.f8b66a1f-e061-4ec5-81d7-72a69457e37d@github.com>

On Fri, 29 Jan 2021 10:53:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This completes the desktop module JNF removal
>> 
>> * remove  -framework JavaNativeFoundation from make files
>> 
>> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
>> 
>> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
>> 
>> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
>> 
>> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
>> 
>> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
>> 
>> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
>> 
>> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
>> 
>> * Remove the single usage of JNFPerformEnvBlock
>> 
>> * replace JNFJavaToNSNumber in single A11Y file with local replacement
>> 
>> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
>> 
>> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>> 
>> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
>
> I mostly have questions about what is missing from this PR. :-) (If this is supposed to remove the final remnants of JNF)
> 
> - There is a disabled warning in `make/autoconf/flags-cflags.m4`, line 173, referring to JavaNativeFoundation. It can presumably be removed. If it triggers individually instead, the warning should be disabled on a per-library basis.
> 
> - In `make/modules/java.base/Lib.gmk`, line 99 & 113, are references to JavaNativeFoundation. It seems that `libosxsecurity` needs to be cleaned from JNF as well. Also, the comments indicate that the exception for STATIC_BUILD can be removed. (You can verify this with `configure --enable-static-build`)
> 
> - In `make/modules/java.desktop/Lib.gmk`, line 129, and `make/modules/java.desktop/lib/Awt2dLibraries.gmk`, line 866 & 094, it seems like `libosx`, `libawt_lwawt`, and `liboxui` also has JNF that needs to be removed. If these are fixed in any of the other issues for the umbrella JDK-8257852, I apologize. I could not figure that out.
> 
> - There is also a test dependency that I have seen being addressed, in `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`.

Right, this is the desktop module as per the first line of the comment.
java.base needs to be removed by the other PR as Erik said.
I  had not spotted it, but I don't see  why the make/test /JtregNativeJdk.gmk case needs to link this framework.
I don't see it being used by the test in question.
But we can just remove it and prove it - but probably a separate PR since it is nothing to do with the desktop module and the autoconf code needs to be updated once everything else is in.

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

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

From gziemski at openjdk.java.net  Fri Jan 29 17:01:51 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Fri, 29 Jan 2021 17:01:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260616: Removing remaining JNF
 dependencies in the java.desktop module
In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
Message-ID: <CcTcYbUlEM0fXgnud0sZelIWOEelhDkV3B6fonTivDg=.c9143c70-2899-420a-960c-bde09a3de514@github.com>

On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race <prr at openjdk.org> wrote:

> This completes the desktop module JNF removal
> 
> * remove  -framework JavaNativeFoundation from make files
> 
> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
> 
> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
> 
> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
> 
> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
> 
> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
> 
> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
> 
> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
> 
> * Remove the single usage of JNFPerformEnvBlock
> 
> * replace JNFJavaToNSNumber in single A11Y file with local replacement
> 
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
> 
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
> 
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)

Changes requested by gziemski (Committer).

src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 608:

> 606:     {
> 607:         // Get string to draw and the length
> 608:         const jchar *unichars = JNFGetStringUTF16UniChars(env, str);

According to `JNFString.h`, the `JNFGetStringUTF16UniChars()` API:

/*
 * Gets UTF16 unichars from a Java string, and checks for errors and raises a JNFException if
 * the unichars cannot be obtained from Java.
 */

raises a (JNFException) if it can't get the chars, but now we simply return if `GetStringChars()` can not return the chars.

Seems like we handle this case differently in the new code now - is this change desired and correct?

src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 601:

> 599:         jchar unichars[len];
> 600:         (*env)->GetStringRegion(env, str, 0, len, unichars);
> 601:         CHECK_EXCEPTION();

Are `JNF_CHECK_AND_RETHROW_EXCEPTION` and `CHECK_EXCEPTION` equivalent?

`JNF_CHECK_AND_RETHROW_EXCEPTION` seems to throw exception, but `CHECK_EXCEPTION` does not?

src/java.desktop/macosx/native/libosxui/ScreenMenu.m line 165:

> 163:  */
> 164: static jlong NSTimeIntervalToJavaMilliseconds(NSTimeInterval interval) {
> 165:     NSTimeInterval interval1970 = interval + NSTimeIntervalSince1970;

Is it required for the APIs using the value from this function to expect the time calculated since Jan 1st 1970?

src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 83:

> 81:                   stringWithFileSystemRepresentation:chs length:len];
> 82:     return result;
> 83: }

Why are we doing:

`java_string -> chars -> NSString -> chars -> [NSFileManager stringWithFileSystemRepresentation]`

?

Why not just get the raw characters form JNI and feed them directly into `[NSFileManager  stringWithFileSystemRepresentation]`, ie:

`java_string -> chars -> [NSFileManager stringWithFileSystemRepresentation]`

and skip the `JavaStringToNSString` step altogether?

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

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

From gziemski at openjdk.java.net  Fri Jan 29 17:05:42 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Fri, 29 Jan 2021 17:05:42 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260616: Removing remaining JNF
 dependencies in the java.desktop module
In-Reply-To: <CcTcYbUlEM0fXgnud0sZelIWOEelhDkV3B6fonTivDg=.c9143c70-2899-420a-960c-bde09a3de514@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <CcTcYbUlEM0fXgnud0sZelIWOEelhDkV3B6fonTivDg=.c9143c70-2899-420a-960c-bde09a3de514@github.com>
Message-ID: <GwkfSf2rgxlm8Oys2rU1G3BfRfwXZ6HHYYD_E9OQ7W8=.6fab8573-80f5-4995-a7d0-248f41e6d8e3@github.com>

On Fri, 29 Jan 2021 16:57:09 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This completes the desktop module JNF removal
>> 
>> * remove  -framework JavaNativeFoundation from make files
>> 
>> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
>> 
>> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
>> 
>> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
>> 
>> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
>> 
>> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
>> 
>> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
>> 
>> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
>> 
>> * Remove the single usage of JNFPerformEnvBlock
>> 
>> * replace JNFJavaToNSNumber in single A11Y file with local replacement
>> 
>> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
>> 
>> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>> 
>> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
>
> Changes requested by gziemski (Committer).

Lots of small changes you had to handle here. Thank you for doing it!

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

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

From prr at openjdk.java.net  Fri Jan 29 17:24:05 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Jan 2021 17:24:05 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260616: Removing remaining JNF
 dependencies in the java.desktop module [v2]
In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
Message-ID: <yyXcEb1t238Ikl36CGQ4ic_Z0N5l5tge4UmA6ifmbBM=.e7ca5367-9087-4088-b600-fce9133f6e53@github.com>

> This completes the desktop module JNF removal
> 
> * remove  -framework JavaNativeFoundation from make files
> 
> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
> 
> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
> 
> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
> 
> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
> 
> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
> 
> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
> 
> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
> 
> * Remove the single usage of JNFPerformEnvBlock
> 
> * replace JNFJavaToNSNumber in single A11Y file with local replacement
> 
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
> 
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
> 
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8260616: Removing remaining JNF dependencies in the java.desktop modul

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2305/files
  - new: https://git.openjdk.java.net/jdk/pull/2305/files/1951d6d8..efab1de5

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

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

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

From prr at openjdk.java.net  Fri Jan 29 17:24:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Jan 2021 17:24:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260616: Removing remaining JNF
 dependencies in the java.desktop module [v2]
In-Reply-To: <GwkfSf2rgxlm8Oys2rU1G3BfRfwXZ6HHYYD_E9OQ7W8=.6fab8573-80f5-4995-a7d0-248f41e6d8e3@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <CcTcYbUlEM0fXgnud0sZelIWOEelhDkV3B6fonTivDg=.c9143c70-2899-420a-960c-bde09a3de514@github.com>
 <GwkfSf2rgxlm8Oys2rU1G3BfRfwXZ6HHYYD_E9OQ7W8=.6fab8573-80f5-4995-a7d0-248f41e6d8e3@github.com>
Message-ID: <nspbo10t5Xki9jncGzubRQmDnGxI2TymnXQbukL6lRk=.511b2f2f-90c5-4f4c-8470-a88affc9c3a0@github.com>

On Fri, 29 Jan 2021 17:02:30 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Changes requested by gziemski (Committer).
>
> Lots of small changes you had to handle here. Thank you for doing it!

I pushed a commit with the remaining -lframework ... removals in the desktop makefiles that I had somehow missed ...

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

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

From psadhukhan at openjdk.java.net  Fri Jan 29 18:05:07 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 29 Jan 2021 18:05:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
Message-ID: <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>

> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
> mach5 job running for several iterations on all platforms is ok. Link in JBS.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Declare m_breakMessageLoop volatile

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2220/files
  - new: https://git.openjdk.java.net/jdk/pull/2220/files/6fdcc0d7..d7dc2a52

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

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

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

From prr at openjdk.java.net  Fri Jan 29 19:56:45 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Jan 2021 19:56:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8260616: Removing remaining JNF
 dependencies in the java.desktop module [v2]
In-Reply-To: <CcTcYbUlEM0fXgnud0sZelIWOEelhDkV3B6fonTivDg=.c9143c70-2899-420a-960c-bde09a3de514@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <CcTcYbUlEM0fXgnud0sZelIWOEelhDkV3B6fonTivDg=.c9143c70-2899-420a-960c-bde09a3de514@github.com>
Message-ID: <Qbm3YYbnAeQycSXj8M4mukJXusNpxlRDTSwWELN6nQM=.e3325063-cf69-4816-adaa-6a54c6a867a1@github.com>

On Fri, 29 Jan 2021 16:23:20 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260616: Removing remaining JNF dependencies in the java.desktop modul
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 601:
> 
>> 599:         jchar unichars[len];
>> 600:         (*env)->GetStringRegion(env, str, 0, len, unichars);
>> 601:         CHECK_EXCEPTION();
> 
> Are `JNF_CHECK_AND_RETHROW_EXCEPTION` and `CHECK_EXCEPTION` equivalent?
> 
> `JNF_CHECK_AND_RETHROW_EXCEPTION` seems to throw exception, but `CHECK_EXCEPTION` does not?

JNF_CHECK_AND_RETHROW_EXCEPTION is this


// JNF_CHECK_AND_RETHROW_EXCEPTION - rethrows exceptions from Java
//
// Takes an exception thrown from Java, and transforms it into an
// NSException. The NSException should bubble up to the upper-most
// JNF_COCOA_ENTER/JNF_COCOA_EXIT pair, and then be re-thrown as
// a Java exception when returning from JNI. This check should be
// done after raw JNI operations which could cause a Java exception
// to be be thrown. The JNF{Get/Set/Call}  macros below do this
// check automatically.
#define JNF_CHECK_AND_RETHROW_EXCEPTION(env)                                                    \
{                                                                                                                                       \
    jthrowable _exception = (*env)->ExceptionOccurred(env);                     \
    if (_exception) [JNFException raise:env throwable:_exception];      \
}

So what it actually does is clear the exception, raise an NSException and when
the code reaches JNF_COCOA_EXIT - which then has to be there - it clears the NSException
and re-throws the Java exception.

So the name of the macro is misleading since this does NOT itself rethrow the exception,
it relies on other code to do that.

CHECK_EXCEPTION will amount to the same - it throws an NSException if there is a Java exception pending.
And it will clear the NSException before exiting back to Java.
The difference is that it doesn't clear the Java Exception and later rethrow it since there is no need
There is one exception to this in  CHECK_EXCEPTION - if this is the main (ie appkit) thread the java exception is cleared since there's no one to return it to ...

> src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 608:
> 
>> 606:     {
>> 607:         // Get string to draw and the length
>> 608:         const jchar *unichars = JNFGetStringUTF16UniChars(env, str);
> 
> According to `JNFString.h`, the `JNFGetStringUTF16UniChars()` API:
> 
> /*
>  * Gets UTF16 unichars from a Java string, and checks for errors and raises a JNFException if
>  * the unichars cannot be obtained from Java.
>  */
> 
> raises a (JNFException) if it can't get the chars, but now we simply return if `GetStringChars()` can not return the chars.
> 
> Seems like we handle this case differently in the new code now - is this change desired and correct?

You are correct, but I decided that here it is fine.
If GetStringChars fails it will return NULL (it does not raise any excptions itself).
I added a check for NULL if NULL we then return from the JNI method to Java.
In the old case it also would return but would additionally propagate that raised exception to Java which JNF
decided to throw into the mix when there's already a standard way of testing failure.
And since we already know str != NULL we are in the realms of something went badly wrong inside the VM for
this to fail. So I decided this was all fine.

> src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 83:
> 
>> 81:                   stringWithFileSystemRepresentation:chs length:len];
>> 82:     return result;
>> 83: }
> 
> Why are we doing:
> 
> `java_string -> chars -> NSString -> chars -> [NSFileManager stringWithFileSystemRepresentation]`
> 
> ?
> 
> Why not just get the raw characters form JNI and feed them directly into `[NSFileManager  stringWithFileSystemRepresentation]`, ie:
> 
> `java_string -> chars -> [NSFileManager stringWithFileSystemRepresentation]`
> 
> and skip the `JavaStringToNSString` step altogether?

I tried to explain the odd-ness of this in the comments preceding the function definition.
Near as I could figure out that intermediate call is needed to do the decomposition since the NSFileManager won't do that.
But this is not exactly my area of expertise and there may be a better way. Who is an expert on the intricacies of the macOS file system naming ?

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

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

From aivanov at openjdk.java.net  Fri Jan 29 20:22:47 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Jan 2021 20:22:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
Message-ID: <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>

On Fri, 29 Jan 2021 18:05:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> This test was failing in our nightly mach5 testing. Appropriate stability code in form of waitForIdle and delay is added.
>> mach5 job running for several iterations on all platforms is ok. Link in JBS.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declare m_breakMessageLoop volatile

src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h line 478:

> 476:     BOOL m_breakOnError;
> 477: 
> 478:     volatile BOOL  m_breakMessageLoop;

Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?

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

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

From serb at openjdk.java.net  Fri Jan 29 23:48:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Jan 2021 23:48:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
 <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>
Message-ID: <EZwnt0x_oWw4rChiTItKrXZGf8Wwcd7uDsZmCYEp6H8=.07293f38-eb31-4c44-ae09-9d5bd2f3313d@github.com>

On Fri, 29 Jan 2021 20:19:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?

The loop should not be removed.

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

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

From psadhukhan at openjdk.java.net  Sat Jan 30 05:12:45 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sat, 30 Jan 2021 05:12:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <EZwnt0x_oWw4rChiTItKrXZGf8Wwcd7uDsZmCYEp6H8=.07293f38-eb31-4c44-ae09-9d5bd2f3313d@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
 <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>
 <EZwnt0x_oWw4rChiTItKrXZGf8Wwcd7uDsZmCYEp6H8=.07293f38-eb31-4c44-ae09-9d5bd2f3313d@github.com>
Message-ID: <RIAmNY3u3cjoGoL4oIVYQuc_inbCjo588QUmziaQqyQ=.4ae71128-8347-4d28-889d-c50db05383d8@github.com>

On Fri, 29 Jan 2021 23:46:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h line 478:
>> 
>>> 476:     BOOL m_breakOnError;
>>> 477: 
>>> 478:     volatile BOOL  m_breakMessageLoop;
>> 
>> Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?
>
>> Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?
> 
> The loop should not be removed.

Unfortunately, volatile modifier has no effect if infinite loop is reinstated..

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

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

From aivanov at openjdk.java.net  Sat Jan 30 12:03:47 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Sat, 30 Jan 2021 12:03:47 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8197825: [Test] Intermittent timeout with
 javax/swing JColorChooser Test [v4]
In-Reply-To: <RIAmNY3u3cjoGoL4oIVYQuc_inbCjo588QUmziaQqyQ=.4ae71128-8347-4d28-889d-c50db05383d8@github.com>
References: <qVxWx23CFMcgQpkAUKVyO1KlL4Vi_ni9wZtmeQNmzKU=.47bca4f0-329a-4563-b075-b22355757a33@github.com>
 <1CsrezyIfA0wd0VG07w9RkwqitKm_k3MbR2HHJftehg=.e8afc861-30ce-4f1a-a4b0-78345b21973c@github.com>
 <G12L2Gb0el3JVIiigiA5McrFbYkhaw38CJF6yovO77M=.a5d4a1c4-17a7-446b-a903-b2a476a98b32@github.com>
 <EZwnt0x_oWw4rChiTItKrXZGf8Wwcd7uDsZmCYEp6H8=.07293f38-eb31-4c44-ae09-9d5bd2f3313d@github.com>
 <RIAmNY3u3cjoGoL4oIVYQuc_inbCjo588QUmziaQqyQ=.4ae71128-8347-4d28-889d-c50db05383d8@github.com>
Message-ID: <fKh6RlNhnhCu4AJ89wXRzQiN2nJ_TRDiqQXmYJPwTII=.43000072-5ac6-4ad2-81c2-cd3e09f5526a@github.com>

On Sat, 30 Jan 2021 05:10:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?
>> 
>> The loop should not be removed.
>
> Unfortunately, volatile modifier has no effect if infinite loop is reinstated..

> > Does this volatile modifier resolve the now-removed infinite loop in `while (!tk.IsDisposed())` in `WToolkit_shutdown`?
> 
> The loop should not be removed.

No, it should not, as you noted previously.

However, making `m_breakMessageLoop` volatile does not look right either. If `QuitMessageLoop` is called from `!IsMainThread()` thread, it is posted as a message to run on the correct thread. Thus `m_breakMessageLoop` should be accessed on a single thread only; if it's the case, volatile is unneeded.

And @prsadhuk's latest test confirms it. There must be something else?

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

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

From serb at openjdk.java.net  Sun Jan 31 11:58:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 31 Jan 2021 11:58:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6211198: ICC_Profile.getInstance(byte[]): IAE
 is not specified
Message-ID: <iRM9axRO_LyFYvouiX4_nqX5-TZTvrFacUWSjt4T5bc=.79828087-55d6-4f0b-9955-65902a9e5f41@github.com>

The specification of the java.awt.color.ICC_Profile.getInstance(byte[]) is updated.
Its implementation changed over time, and different exceptions were thrown, but since JDK-8013430 always throws an IllegalArgumentException on null and invalid data.

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

Commit messages:
 - Merge branch 'master' into JDK-6211198
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/2328/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2328&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6211198
  Stats: 51 lines in 3 files changed: 44 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2328.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2328/head:pull/2328

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

From serb at openjdk.java.net  Sun Jan 31 11:58:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 31 Jan 2021 11:58:57 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6211198: ICC_Profile.getInstance(byte[]):
 IAE is not specified
In-Reply-To: <iRM9axRO_LyFYvouiX4_nqX5-TZTvrFacUWSjt4T5bc=.79828087-55d6-4f0b-9955-65902a9e5f41@github.com>
References: <iRM9axRO_LyFYvouiX4_nqX5-TZTvrFacUWSjt4T5bc=.79828087-55d6-4f0b-9955-65902a9e5f41@github.com>
Message-ID: <NmZTlBcn8BqQ9T_rx5r36SBiXBYv4P0jPoIHEDRE5j4=.62a37745-78dd-439f-92d2-6733529943ea@github.com>

On Sun, 31 Jan 2021 01:41:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The specification of the java.awt.color.ICC_Profile.getInstance(byte[]) is updated.
> Its implementation changed over time, and different exceptions were thrown, but since JDK-8013430 always throws an IllegalArgumentException on null and invalid data.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 967:

> 965:      *         Profile data
> 966:      */
> 967:     public static ICC_Profile getInstance(InputStream s) throws IOException {

This additional check was needed when the getInstance(byte[]) thrown NPE on null

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

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

From akozlov at openjdk.java.net  Sun Jan 31 20:14:01 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Sun, 31 Jan 2021 20:14:01 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v8]
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: <ugV_PtxgaQkJQw3i1cwYiaKZ46--TZfgdVsuhQd5_3Y=.5b39eb44-1398-41b1-8bdf-2e6a3149e865@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 62 commits:

 - Merge branch 'master' into jdk-macos
 - Update copyright year for BsdAARCH64ThreadContext.java
 - Fix inclusing of StubRoutines header
 - Redo buildsys fix
 - Revert harfbuzz changes, disable warnings for it
 - Little adjustement of SlowSignatureHandler
 - Partially bring previous commit
 - Revert "Address feedback for signature generators"
   
   This reverts commit 50b55f6684cd21f8b532fa979b7b6fbb4613266d.
 - Refactor CDS disabling
 - Redo builsys support for aarch64-darwin
 - ... and 52 more: https://git.openjdk.java.net/jdk/compare/8a9004da...b421e0b4

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=07
  Stats: 3266 lines in 114 files changed: 3164 ins; 41 del; 61 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 vkempik at openjdk.java.net  Sun Jan 31 20:14:02 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Sun, 31 Jan 2021 20:14:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8253795: Implementation of JEP 391:
 macOS/AArch64 Port [v8]
In-Reply-To: <GUQ9iV90tXzdUOtyjcIJygM7qBCcUtSHVOol8hOK2OE=.7b3ab947-f835-43d4-a852-cde094efbf62@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <W8UGeXzEc_BvnLqIZ7FZF6zks4U39dAZaXCzSGDS1qw=.1f3badd9-df84-4f00-9e1d-d959780fb997@github.com>
 <h9On7_RFadcLwhW15R4Jig9PZ0y9JoMI2diiqXv99eY=.9b814ff7-64cf-496f-a507-0a8f86070c2d@github.com>
 <GUQ9iV90tXzdUOtyjcIJygM7qBCcUtSHVOol8hOK2OE=.7b3ab947-f835-43d4-a852-cde094efbf62@github.com>
Message-ID: <0-H97G4l5XqFtiEUbNAqrP_j143iny5kkF0tsiAqMvQ=.2396963b-db5d-469e-bc30-511f754a600a@github.com>

On Mon, 25 Jan 2021 09:48:46 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Would you like me to do something about it now? The problem is that the functions of SlowSignatureHandler are subtly different, so it will be multiple tables, not sure how many. Such change is another candidate for a separate code enhancement, which I would like not to mix into the JEP implementation (it's already not a small change :)). But if you think it would be a good thing, please let me know. In another case, I'll add this to a queue of follow-up enhancements.
>
> I'm not sure it can wait. This change turns already-messy code into something significantly messier, to the extent that it's not really good enough to go into mainline.

Hello
Does this look like something in the right direction ? 

https://github.com/VladimirKempik/jdk/commit/c2820734f4b10148154085a70d380b8c5775fa49

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

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

From martin.doerr at sap.com  Thu Jan  7 17:16:41 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 07 Jan 2021 17:16:41 -0000
Subject: [OpenJDK 2D-Dev] [11u] Backport of 8247872: Upgrade HarfBuzz to the
 latest 2.7.2
Message-ID: <AM4PR02MB3057E76ABABD7ED56E2F7CFF9AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi,

I've created a jdk11u backport of JDK-8247872: Upgrade HarfBuzz to the latest 2.7.2
http://cr.openjdk.java.net/~mdoerr/8247872_harfbuzz_11u/webrev.00/

I had to resolve it a bit manually [1].
However, the main problem is that it heavily uses C++11, so easiest solution is to add HARFBUZZ_CFLAGS := -std=c++11.
This works for all supported compilers [2] except xlC on AIX and sun studio on Solaris.

I could envision different solutions:

  1.  Change code to work with older C++ standard. I don't want to do this because this seems to be significant effort and is probably error prone (I'm not really familiar with the code and TMP code is hard to adapt). And we may have to repeat it for future HB upgrades.
  2.  Upgrade compilers: This is possible on AIX. We'd need to backport some build changes and use xlclang++. But I guess there's no solaris studio available which can compile it. Note that the original bug was blocked by JEP 362: Deprecate the Solaris and SPARC Ports.
  3.  Use configure flag --with-harfbuzz=system on the problematic platforms. Disadvantage: All machines require new enough version of libharfbuzz installed.
  4.  Skip JDK-8247872 backport. Oracle must have had a reason for backporting it to 11.0.11-oracle, so some jdk11u users will probably want to have it at least on the main platforms.

Any comments or ideas will be appreciated.

Best regards,
Martin


[1] Resolution steps:
- Manually delete hb-dsalgs.hh.
- Awt2dLibraries.gmk is at a different location in 11u.
- Integrate a few hunks manually due to minor adaptations for Solaris build: see http://cr.openjdk.java.net/~mdoerr/8247872_harfbuzz_11u/8247872_harfbuzz_failing_hunks.txt
- Add HARFBUZZ_CFLAGS := -std=c++11 to Awt2dLibraries.gmk.

[2] Supported compilers:
https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20210107/1141c48a/attachment-0001.htm>

From martin.doerr at sap.com  Fri Jan  8 10:36:28 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 08 Jan 2021 10:36:28 -0000
Subject: [OpenJDK 2D-Dev] [11u] Backport of 8247872: Upgrade HarfBuzz to
 the latest 2.7.2
In-Reply-To: <AM4PR02MB31389CB17EAFBB97EDFAF7CE8AAF0@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3057E76ABABD7ED56E2F7CFF9AAF0@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <32e197f5ec5fce10f1aaf06260c54b0328c7549b.camel@redhat.com>
 <AM4PR02MB31389CB17EAFBB97EDFAF7CE8AAF0@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB30577C3A06C00B2213D7425B9AAE0@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi Christoph,

> is there any other reason why harfbuzz 2.7.2 needs to be backported to
> OpenJDK 11 beyond the fact that Oracle did it?
I don't have other reasons at the moment. I'd be fine with deferring it until anyone has a demand. I'm just evaluating options in order to be prepared.

> I think both, having to uplift compiler requirements and/or requiring
> additional system dependencies, would be a price too high to pay for this.
> And modifying the code to work without c++11 features doesn't seem
> feasible.
I agree with that. Note that officially supported compilers for "main platforms" (not AIX, not Solaris) don't need upgrades (https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms).
It should also be possible to add both versions and modify the build such that it uses the old HarfBuzz version only for old compilers. But I'd vote for that only if we really need the new version on "main platforms".

Best regards,
Martin


> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Donnerstag, 7. Januar 2021 23:42
> To: Severin Gehwolf <sgehwolf at redhat.com>; Doerr, Martin
> <martin.doerr at sap.com>; jdk-updates-dev at openjdk.java.net; 2d-
> dev at openjdk.java.net
> Subject: RE: [OpenJDK 2D-Dev] [11u] Backport of 8247872: Upgrade HarfBuzz
> to the latest 2.7.2
> 
> Hi,
> 
> is there any other reason why harfbuzz 2.7.2 needs to be backported to
> OpenJDK 11 beyond the fact that Oracle did it?
> 
> I think both, having to uplift compiler requirements and/or requiring
> additional system dependencies, would be a price too high to pay for this.
> And modifying the code to work without c++11 features doesn't seem
> feasible.
> 
> Just my .02? at this point...
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: 2d-dev <2d-dev-retn at openjdk.java.net> On Behalf Of Severin
> > Gehwolf
> > Sent: Donnerstag, 7. Januar 2021 18:32
> > To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-
> > dev at openjdk.java.net; 2d-dev at openjdk.java.net
> > Subject: Re: [OpenJDK 2D-Dev] [11u] Backport of 8247872: Upgrade
> HarfBuzz
> > to the latest 2.7.2
> >
> > On Thu, 2021-01-07 at 17:16 +0000, Doerr, Martin wrote:
> > > Hi,
> > >
> > > I've created a jdk11u backport of JDK-8247872: Upgrade HarfBuzz to
> > > the latest 2.7.2
> > > http://cr.openjdk.java.net/~mdoerr/8247872_harfbuzz_11u/webrev.00/
> > >
> > > I had to resolve it a bit manually [1].
> > > However, the main problem is that it heavily uses C++11, so easiest
> > > solution is to add HARFBUZZ_CFLAGS := -std=c++11.
> > > This works for all supported compilers [2] except xlC on AIX and sun
> > > studio on Solaris.
> >
> > We are building vanilla JDK 11 builds with gcc 4.4.7 which doesn't
> > support the -std=c++11 option. We've had issues in that area before.
> > See JDK-8256557.
> >
> > Thanks,
> > Severin
> >
> > > I could envision different solutions:
> > >
> > > ? 1.? Change code to work with older C++ standard. I don't want to do
> > > this because this seems to be significant effort and is probably
> > > error prone (I'm not really familiar with the code and TMP code is
> > > hard to adapt). And we may have to repeat it for future HB upgrades.
> > > ? 2.? Upgrade compilers: This is possible on AIX. We'd need to
> > > backport some build changes and use xlclang++. But I guess there's no
> > > solaris studio available which can compile it. Note that the original
> > > bug was blocked by JEP 362: Deprecate the Solaris and SPARC Ports.
> > > ? 3.? Use configure flag --with-harfbuzz=system on the problematic
> > > platforms. Disadvantage: All machines require new enough version of
> > > libharfbuzz installed.
> > > ? 4.? Skip JDK-8247872 backport. Oracle must have had a reason for
> > > backporting it to 11.0.11-oracle, so some jdk11u users will probably
> > > want to have it at least on the main platforms.
> > >
> > > Any comments or ideas will be appreciated.
> > >
> > > Best regards,
> > > Martin
> > >
> > >
> > > [1] Resolution steps:
> > > - Manually delete hb-dsalgs.hh.
> > > - Awt2dLibraries.gmk is at a different location in 11u.
> > > - Integrate a few hunks manually due to minor adaptations for Solaris
> > > build: see
> > >
> >
> http://cr.openjdk.java.net/~mdoerr/8247872_harfbuzz_11u/8247872_harfb
> > uzz_failing_hunks.txt
> > > - Add HARFBUZZ_CFLAGS := -std=c++11 to Awt2dLibraries.gmk.
> > >
> > > [2] Supported compilers:
> > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
> > >
> >