From avu at openjdk.java.net  Tue Jun  1 09:26:29 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 1 Jun 2021 09:26:29 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8261549: Adjust memory size in MTLTexurePool.m
Message-ID: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>

Used MTLDevice recommendedMaxWorkingSetSize property for optimal size of the texture pool

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

Commit messages:
 - 8261549: Adjust memory size in MTLTexurePool.m

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

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

From alanb at openjdk.java.net  Tue Jun  1 12:50:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 12:50:29 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <dVFpffOKyZHh8laXoFtu1wOUx8nLCS9d12qsoSUE5Bk=.632c4211-41df-40b4-8e07-ee8c3cb249f5@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

System.setSecurityManagerDirect looks a bit ugly now. Can this be renamed to implSetSecurityManager and avoid the line break in the  middle of the declaration?

The usage of System.err usage in setSecurityManager also needs to be re-examined as this will run arbitrary code when System.err can be changed. To fix this will require capturing the stream at startup (as was done with the illegal access logger). It's okay to integrate with what you have for the first push and we can fix this issue with System.err when the warning message is changed to the intended message.

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

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

From weijun at openjdk.java.net  Tue Jun  1 15:06:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:06:41 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v7]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <DSVYh67KJe9RW8wMcOpG0R8F4Jx4HYzwW66XEV-EH1w=.cb0b76eb-c433-4ed1-bf62-e227082768f3@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  rename setSecurityManagerDirect to implSetSecurityManager

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a

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

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

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

From weijun at openjdk.java.net  Tue Jun  1 15:21:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 1 Jun 2021 15:21:33 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v8]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang 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 from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

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

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=07
  Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From alanb at openjdk.java.net  Tue Jun  1 16:05:29 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 1 Jun 2021 16:05:29 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <M0Mj0BK_4OBlu3dwDgSWnaM8KDpkL0KxAJldFL7q-eY=.31a0aa64-5a69-42df-bf80-09b4e7a3c144@github.com>

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang 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 from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by alanb (Reviewer).

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

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

From joehw at openjdk.java.net  Tue Jun  1 16:28:27 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 1 Jun 2021 16:28:27 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v8]
In-Reply-To: <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <FWTxAZSA93crdQbR0z3qzbQYwiC0DD53Xb36rKomdvc=.0f797620-eebc-4a6d-bed7-51a912a0c957@github.com>
Message-ID: <rwSPwilSFt5efKcqrbureXYq8SmLxHMgrE_psXV-S9A=.87124c9e-112f-4a4e-80de-26bfa32fa995@github.com>

On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang 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 from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by joehw (Reviewer).

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

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

From weijun at openjdk.java.net  Wed Jun  2 12:01:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:30 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266459: Implement JEP 411: Deprecate the
 Security Manager for Removal [v9]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <HOkSwSOf7m0eP71_pjxacSX3FnXw8CbONP_DbY0mCno=.969b9543-c6d1-4001-afac-d8cb337fd60f@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - copyright years
 - merge from master, resolve one conflict
 - Merge branch 'master'
 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/19450b99...331389b5

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

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=08
  Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

From weijun at openjdk.java.net  Wed Jun  2 12:01:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 12:01:33 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8266459: Implement JEP 411: Deprecate
 the Security Manager for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <PsbFcEhvCahb4zpsvIhOlxvAbJK7DTE3-umT3Nsn5dY=.fe038b5f-dc17-4d4f-a19b-ed8c238c7d58@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

This pull request has now been integrated.

Changeset: 6765f902
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1
Stats:     2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod

8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Co-authored-by: Sean Mullan <mullan at openjdk.org>
Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea

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

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

From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net  Wed Jun  2 12:02:38 2021
From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot])
Date: Wed, 2 Jun 2021 12:02:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8267521: Post JEP 411 refactoring:
 maximum covering > 50K [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <PSyJvVFJ9ZdvF7KLSUwpd2ZUNj_zgTnlnfb894o0s2M=.3d72b382-7e1c-45b4-b704-541e57dfab0e@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout 8266459
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

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

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

From weijun at openjdk.java.net  Wed Jun  2 15:40:55 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:40:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8267521: Post JEP 411 refactoring:
 maximum covering > 50K [v4]
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <iWLNwxV2CvTVXj57-NbeWHor64Ab3P7461jOk1XxoJ0=.91556668-25eb-40b4-afae-730f9c1d621f@github.com>

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.
> 
> I'll add a copyright year update commit before integration.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8267521: Post JEP 411 refactoring: maximum covering > 50K

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

Changes: https://git.openjdk.java.net/jdk/pull/4138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=03
  Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

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

From weijun at openjdk.java.net  Wed Jun  2 15:51:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 2 Jun 2021 15:51:33 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8267521: Post JEP 411 refactoring:
 maximum covering > 50K
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <zkd_bofYu1MISkzzGFuI8utKnvp_M7M4icu-ws3be7k=.d7621e87-5890-492f-a64a-187e1f9eb9ed@github.com>

On Fri, 21 May 2021 01:52:27 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.
> 
> I'll add a copyright year update commit before integration.

This pull request has now been integrated.

Changeset: 508cec75
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b
Stats:     245 lines in 18 files changed: 140 ins; 39 del; 66 mod

8267521: Post JEP 411 refactoring: maximum covering > 50K

Reviewed-by: dfuchs, prr

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

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

From aghaisas at openjdk.java.net  Fri Jun  4 11:23:06 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 4 Jun 2021 11:23:06 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F
Message-ID: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>

This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.

**Issue :**
SwingSet2 Demo - As reported in JBS description
J2DDemo - As reported in a comment on JBS

**Root Cause :** 
DrawPixel path is used only with uiScale=1.0. 
MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
As mentioned in the documentation -
https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc

"The vertex shader must provide [[point_size]], or the point size is undefined."

In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.

**Solution :**
 Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.

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

Commit messages:
 - r

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

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

From jdv at openjdk.java.net  Fri Jun  4 12:50:56 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 4 Jun 2021 12:50:56 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F
In-Reply-To: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
Message-ID: <BjnMUpnqqmGopOMDQZr32tD_t67W1jBd6W0d_D05lkg=.e2567286-5d24-42ce-a53c-c028d567d127@github.com>

On Fri, 4 Jun 2021 11:14:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
> 
> **Issue :**
> SwingSet2 Demo - As reported in JBS description
> J2DDemo - As reported in a comment on JBS
> 
> **Root Cause :** 
> DrawPixel path is used only with uiScale=1.0. 
> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
> As mentioned in the documentation -
> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
> 
> "The vertex shader must provide [[point_size]], or the point size is undefined."
> 
> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
> 
> **Solution :**
>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.

LGTM.
Please add CI test run link in JBS, once it is completed.

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

Marked as reviewed by jdv (Reviewer).

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

From serb at openjdk.java.net  Sat Jun  5 07:48:58 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 5 Jun 2021 07:48:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F
In-Reply-To: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
Message-ID: <JeSHXT_EaEnP1j0X_SPAvsyHqKEMSV0RyIPr5tluW9U=.bade5fb7-941b-47aa-8c00-dfebc0802238@github.com>

On Fri, 4 Jun 2021 11:14:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
> 
> **Issue :**
> SwingSet2 Demo - As reported in JBS description
> J2DDemo - As reported in a comment on JBS
> 
> **Root Cause :** 
> DrawPixel path is used only with uiScale=1.0. 
> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
> As mentioned in the documentation -
> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
> 
> "The vertex shader must provide [[point_size]], or the point size is undefined."
> 
> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
> 
> **Solution :**
>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.

Is it possible to cover this fix with some automated test? Looks non of existed tests found this issue.

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

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

From prr at openjdk.java.net  Sat Jun  5 23:48:59 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 5 Jun 2021 23:48:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8261549: Adjust memory size in
 MTLTexurePool.m
In-Reply-To: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>
References: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>
Message-ID: <SQjKUgq9msWoZQLUoW2V8CsKj5i2aEayOAWROqnKbIg=.e27d7147-0767-425c-b02d-51c79eff703c@github.com>

On Tue, 1 Jun 2021 09:20:07 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Used MTLDevice recommendedMaxWorkingSetSize property for optimal size of the texture pool

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m line 328:

> 326:     if (_maxPoolMemory < MAX_POOL_MEMORY) {
> 327:         _maxPoolMemory = MAX_POOL_MEMORY;
> 328:     }

The Apple 5K retina is 5120?by?2880 pixels

So we start off with a number that is too small
#define SCREEN_MEMORY_SIZE_4K (4096*2160*4) //~33,7 mb
and then divide it by 2
#define MAX_POOL_MEMORY SCREEN_MEMORY_SIZE_4K/2

and I have no idea what a typical size is for 
self.device.recommendedMaxWorkingSetSize
which we are also dividing by 2.

So I have no idea what the logic is behind all these numbers.

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

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

From avu at openjdk.java.net  Mon Jun  7 10:42:02 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 7 Jun 2021 10:42:02 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8261549: Adjust memory size in
 MTLTexurePool.m
In-Reply-To: <SQjKUgq9msWoZQLUoW2V8CsKj5i2aEayOAWROqnKbIg=.e27d7147-0767-425c-b02d-51c79eff703c@github.com>
References: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>
 <SQjKUgq9msWoZQLUoW2V8CsKj5i2aEayOAWROqnKbIg=.e27d7147-0767-425c-b02d-51c79eff703c@github.com>
Message-ID: <sshG_qIUkQUzfaphw9UWEvTlp5DF0dRZsKh1kV5HzQQ=.becf1662-2b77-46cf-b89d-9326e53a4823@github.com>

On Sat, 5 Jun 2021 23:46:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> Used MTLDevice recommendedMaxWorkingSetSize property for optimal size of the texture pool
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m line 328:
> 
>> 326:     if (_maxPoolMemory < MAX_POOL_MEMORY) {
>> 327:         _maxPoolMemory = MAX_POOL_MEMORY;
>> 328:     }
> 
> The Apple 5K retina is 5120?by?2880 pixels
> 
> So we start off with a number that is too small
> #define SCREEN_MEMORY_SIZE_4K (4096*2160*4) //~33,7 mb
> and then divide it by 2
> #define MAX_POOL_MEMORY SCREEN_MEMORY_SIZE_4K/2
> 
> and I have no idea what a typical size is for 
> self.device.recommendedMaxWorkingSetSize
> which we are also dividing by 2.
> 
> So I have no idea what the logic is behind all these numbers.

> The Apple 5K retina is 5120?by?2880 pixels
> 
> So we start off with a number that is too small
> #define SCREEN_MEMORY_SIZE_4K (4096_2160_4) //~33,7 mb
> and then divide it by 2
> #define MAX_POOL_MEMORY SCREEN_MEMORY_SIZE_4K/2

I didn't touch this number here, they worked well within our EA testing cycles. So, I decided to use it as a fallback. We can extend it to 5K though.

> and I have no idea what a typical size is for
> self.device.recommendedMaxWorkingSetSize
> which we are also dividing by 2.

This size typically much much bigger than  SCREEN_MEMORY_SIZE_4K 
 - 4GB on Radeon Pro 560X 4GB
 - 1.5GB Intel UHD Graphics 630 1536 MB  (MBP 2019)
 Looks like it corresponds to the amount of VRAM however the doc says that OS may set another value
 
> An approximation of how much memory, in bytes, this device can use with good performance.

I don't think that it's a good idea to take all the recommended VRAM, so decided to divide it by 2.

> 
> So I have no idea what the logic is behind all these numbers.

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

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

From aghaisas at openjdk.java.net  Mon Jun  7 12:03:36 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 7 Jun 2021 12:03:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F
In-Reply-To: <JeSHXT_EaEnP1j0X_SPAvsyHqKEMSV0RyIPr5tluW9U=.bade5fb7-941b-47aa-8c00-dfebc0802238@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
 <JeSHXT_EaEnP1j0X_SPAvsyHqKEMSV0RyIPr5tluW9U=.bade5fb7-941b-47aa-8c00-dfebc0802238@github.com>
Message-ID: <bUVVgOekFCR9lFHrgpmvsB-fj2gTJR7zLfwIiWKupOI=.c2b5f8b4-8dee-47e4-be3a-5c9b39d8625a@github.com>

On Sat, 5 Jun 2021 07:46:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Is it possible to cover this fix with some automated test? Looks non of existed tests found this issue.

Draw Pixel operation is unpredictable on macOS M1 with metal pipeline if [[point_size]] is not defined. Due to this unpredictability it is difficult to write an automated test.
I have developed a test which successfully detects this failure. It needs to be run with "-Dsun.java2d.uiScale=1.0". I will update the PR soon.

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

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

From aghaisas at openjdk.java.net  Mon Jun  7 12:03:35 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 7 Jun 2021 12:03:35 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F [v2]
In-Reply-To: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
Message-ID: <n1w7EyG1aGaf5eKCR4Oewgw1IILYW_kTPGZsQ-XAx3I=.90fdce62-643f-4772-a3f8-b0eb7c6c6d35@github.com>

> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
> 
> **Issue :**
> SwingSet2 Demo - As reported in JBS description
> J2DDemo - As reported in a comment on JBS
> 
> **Root Cause :** 
> DrawPixel path is used only with uiScale=1.0. 
> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
> As mentioned in the documentation -
> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
> 
> "The vertex shader must provide [[point_size]], or the point size is undefined."
> 
> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
> 
> **Solution :**
>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  add automated test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4356/files
  - new: https://git.openjdk.java.net/jdk/pull/4356/files/b61e512e..751c85cf

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

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

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

From avu at openjdk.java.net  Mon Jun  7 15:12:44 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 7 Jun 2021 15:12:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8261549: Adjust memory size in
 MTLTexurePool.m [v2]
In-Reply-To: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>
References: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>
Message-ID: <peI9_l2KQWyVAQ74f117rH9S6UOiOflddXjwGT8xwSE=.c3777706-e45e-4664-a504-0cf35ce4bfe5@github.com>

> Used MTLDevice recommendedMaxWorkingSetSize property for optimal size of the texture pool

Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:

  8261549: Adjust memory size in MTLTexurePool.m
  
  Increased default pool size

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4279/files
  - new: https://git.openjdk.java.net/jdk/pull/4279/files/2c52dbfb..8eaafea6

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

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

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

From prr at openjdk.java.net  Mon Jun  7 16:43:16 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Jun 2021 16:43:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8261549: Adjust memory size in
 MTLTexurePool.m [v2]
In-Reply-To: <peI9_l2KQWyVAQ74f117rH9S6UOiOflddXjwGT8xwSE=.c3777706-e45e-4664-a504-0cf35ce4bfe5@github.com>
References: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>
 <peI9_l2KQWyVAQ74f117rH9S6UOiOflddXjwGT8xwSE=.c3777706-e45e-4664-a504-0cf35ce4bfe5@github.com>
Message-ID: <OH6u5NwV7s6_ncgb8LSpzSx36uRZfKAdBT_icoXQgM0=.cf9292d9-99f2-4fbc-a75f-5f9ba16ed392@github.com>

On Mon, 7 Jun 2021 15:12:44 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Used MTLDevice recommendedMaxWorkingSetSize property for optimal size of the texture pool
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261549: Adjust memory size in MTLTexurePool.m
>   
>   Increased default pool size

Marked as reviewed by prr (Reviewer).

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

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

From prr at openjdk.java.net  Mon Jun  7 16:43:16 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Jun 2021 16:43:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8261549: Adjust memory size in
 MTLTexurePool.m [v2]
In-Reply-To: <sshG_qIUkQUzfaphw9UWEvTlp5DF0dRZsKh1kV5HzQQ=.becf1662-2b77-46cf-b89d-9326e53a4823@github.com>
References: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>
 <SQjKUgq9msWoZQLUoW2V8CsKj5i2aEayOAWROqnKbIg=.e27d7147-0767-425c-b02d-51c79eff703c@github.com>
 <sshG_qIUkQUzfaphw9UWEvTlp5DF0dRZsKh1kV5HzQQ=.becf1662-2b77-46cf-b89d-9326e53a4823@github.com>
Message-ID: <022jr-sfk83ZdmFjdUBMz5paUfwEIsQXQ6CiWeJWwTI=.866b50fa-79b0-46cc-ada2-3a9b9b0da2f2@github.com>

On Mon, 7 Jun 2021 10:39:26 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m line 328:
>> 
>>> 326:     if (_maxPoolMemory < MAX_POOL_MEMORY) {
>>> 327:         _maxPoolMemory = MAX_POOL_MEMORY;
>>> 328:     }
>> 
>> The Apple 5K retina is 5120?by?2880 pixels
>> 
>> So we start off with a number that is too small
>> #define SCREEN_MEMORY_SIZE_4K (4096*2160*4) //~33,7 mb
>> and then divide it by 2
>> #define MAX_POOL_MEMORY SCREEN_MEMORY_SIZE_4K/2
>> 
>> and I have no idea what a typical size is for 
>> self.device.recommendedMaxWorkingSetSize
>> which we are also dividing by 2.
>> 
>> So I have no idea what the logic is behind all these numbers.
>
>> The Apple 5K retina is 5120?by?2880 pixels
>> 
>> So we start off with a number that is too small
>> #define SCREEN_MEMORY_SIZE_4K (4096_2160_4) //~33,7 mb
>> and then divide it by 2
>> #define MAX_POOL_MEMORY SCREEN_MEMORY_SIZE_4K/2
> 
> I didn't touch this number here, they worked well within our EA testing cycles. So, I decided to use it as a fallback. We can extend it to 5K though.
> 
>> and I have no idea what a typical size is for
>> self.device.recommendedMaxWorkingSetSize
>> which we are also dividing by 2.
> 
> This size typically much much bigger than  SCREEN_MEMORY_SIZE_4K 
>  - 4GB on Radeon Pro 560X 4GB
>  - 1.5GB Intel UHD Graphics 630 1536 MB  (MBP 2019)
>  Looks like it corresponds to the amount of VRAM however the doc says that OS may set another value
>  
>> An approximation of how much memory, in bytes, this device can use with good performance.
> 
> I don't think that it's a good idea to take all the recommended VRAM, so decided to divide it by 2.
> 
>> 
>> So I have no idea what the logic is behind all these numbers.

OK. Can you add some of this info to the bug report.
Notabkly the typical size for self.device.recommendedMaxWorkingSetSize

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

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

From avu at openjdk.java.net  Mon Jun  7 17:40:21 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 7 Jun 2021 17:40:21 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8261549: Adjust memory size in
 MTLTexurePool.m
In-Reply-To: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>
References: <Vt44HTCdylPbYwOYv5fyjIU6yUng8s5GkBu_ml3MgiQ=.5eed3957-2de2-480e-b186-2d7224888249@github.com>
Message-ID: <pYCfXjYoVgi2SuDNs82SG7febOcCnuy0XcWVLp1n87Y=.96be1305-8c74-4d58-bbaa-efed0b2b2fc5@github.com>

On Tue, 1 Jun 2021 09:20:07 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Used MTLDevice recommendedMaxWorkingSetSize property for optimal size of the texture pool

This pull request has now been integrated.

Changeset: 7e55569e
Author:    Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e55569edee84dcae63fbdf1f89fefa554360736
Stats:     15 lines in 1 file changed: 11 ins; 1 del; 3 mod

8261549: Adjust memory size in MTLTexurePool.m

Reviewed-by: prr

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

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

From serb at openjdk.java.net  Mon Jun  7 17:48:21 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 7 Jun 2021 17:48:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F [v2]
In-Reply-To: <n1w7EyG1aGaf5eKCR4Oewgw1IILYW_kTPGZsQ-XAx3I=.90fdce62-643f-4772-a3f8-b0eb7c6c6d35@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
 <n1w7EyG1aGaf5eKCR4Oewgw1IILYW_kTPGZsQ-XAx3I=.90fdce62-643f-4772-a3f8-b0eb7c6c6d35@github.com>
Message-ID: <xBfQyvO_AzHVTNPuY4KEfb0BxhyZ3uYHr0bNOvEXByE=.27a9d464-a767-4abc-830b-89fff7409aa0@github.com>

On Mon, 7 Jun 2021 12:03:35 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
>> 
>> **Issue :**
>> SwingSet2 Demo - As reported in JBS description
>> J2DDemo - As reported in a comment on JBS
>> 
>> **Root Cause :** 
>> DrawPixel path is used only with uiScale=1.0. 
>> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
>> As mentioned in the documentation -
>> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
>> 
>> "The vertex shader must provide [[point_size]], or the point size is undefined."
>> 
>> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
>> 
>> **Solution :**
>>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add automated test

Looks fine, I assume that you checked the test via mach5 so we will not get a similar bug on other platforms.

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

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

From serb at openjdk.java.net  Mon Jun  7 17:50:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 7 Jun 2021 17:50:23 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8264666: Reuse
 Math.multiplyExact/addExact in the LCMSImageLayout class
In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com>
Message-ID: <rRUp7N5GFxNd1xbL26oqGtgyY75o5zdUJHn97yVtQvM=.932ed666-524b-4098-b1a6-632b13a9cbed@github.com>

On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions.
> - Cleanup: the usage of do/while(false) is removed

not now

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

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

From prr at openjdk.java.net  Mon Jun  7 20:51:21 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 7 Jun 2021 20:51:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F [v2]
In-Reply-To: <n1w7EyG1aGaf5eKCR4Oewgw1IILYW_kTPGZsQ-XAx3I=.90fdce62-643f-4772-a3f8-b0eb7c6c6d35@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
 <n1w7EyG1aGaf5eKCR4Oewgw1IILYW_kTPGZsQ-XAx3I=.90fdce62-643f-4772-a3f8-b0eb7c6c6d35@github.com>
Message-ID: <NCh0nPK8BDws79FnIfZ2_W2g-6hjYulE7ISsmKdTRJM=.a8ad5936-b133-4b91-b648-509edbc9344e@github.com>

On Mon, 7 Jun 2021 12:03:35 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
>> 
>> **Issue :**
>> SwingSet2 Demo - As reported in JBS description
>> J2DDemo - As reported in a comment on JBS
>> 
>> **Root Cause :** 
>> DrawPixel path is used only with uiScale=1.0. 
>> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
>> As mentioned in the documentation -
>> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
>> 
>> "The vertex shader must provide [[point_size]], or the point size is undefined."
>> 
>> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
>> 
>> **Solution :**
>>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add automated test

Marked as reviewed by prr (Reviewer).

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

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

From jdv at openjdk.java.net  Tue Jun  8 04:02:22 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 8 Jun 2021 04:02:22 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F [v2]
In-Reply-To: <n1w7EyG1aGaf5eKCR4Oewgw1IILYW_kTPGZsQ-XAx3I=.90fdce62-643f-4772-a3f8-b0eb7c6c6d35@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
 <n1w7EyG1aGaf5eKCR4Oewgw1IILYW_kTPGZsQ-XAx3I=.90fdce62-643f-4772-a3f8-b0eb7c6c6d35@github.com>
Message-ID: <JrScLk4jwJppI_gdjvAHzQWCFjEGp2003WFO-s4BbLI=.04cdff88-d58c-437a-8212-d22aa7df7f99@github.com>

On Mon, 7 Jun 2021 12:03:35 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
>> 
>> **Issue :**
>> SwingSet2 Demo - As reported in JBS description
>> J2DDemo - As reported in a comment on JBS
>> 
>> **Root Cause :** 
>> DrawPixel path is used only with uiScale=1.0. 
>> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
>> As mentioned in the documentation -
>> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
>> 
>> "The vertex shader must provide [[point_size]], or the point size is undefined."
>> 
>> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
>> 
>> **Solution :**
>>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add automated test

Marked as reviewed by jdv (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Tue Jun  8 07:02:15 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 8 Jun 2021 07:02:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F [v2]
In-Reply-To: <n1w7EyG1aGaf5eKCR4Oewgw1IILYW_kTPGZsQ-XAx3I=.90fdce62-643f-4772-a3f8-b0eb7c6c6d35@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
 <n1w7EyG1aGaf5eKCR4Oewgw1IILYW_kTPGZsQ-XAx3I=.90fdce62-643f-4772-a3f8-b0eb7c6c6d35@github.com>
Message-ID: <c0cZU-Zm4HDmdCTG54pVWVAidLF2oqASE8IBA3x6gp8=.168071b9-860c-46ee-b146-96f0f73e092a@github.com>

On Mon, 7 Jun 2021 12:03:35 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
>> 
>> **Issue :**
>> SwingSet2 Demo - As reported in JBS description
>> J2DDemo - As reported in a comment on JBS
>> 
>> **Root Cause :** 
>> DrawPixel path is used only with uiScale=1.0. 
>> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
>> As mentioned in the documentation -
>> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
>> 
>> "The vertex shader must provide [[point_size]], or the point size is undefined."
>> 
>> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
>> 
>> **Solution :**
>>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add automated test

test/jdk/java/awt/Graphics/DrawOvalTest.java line 54:

> 52:         render(vi.createGraphics());
> 53: 
> 54:         BufferedImage snapshot = vi.getSnapshot();

I guess we need to obtain this snapshot in a do-while loop to check for volatile image contents is not lost similar to 

do {
vi.validate(gc);
render();
vi.getShapshot();
} while(vi.getContentsLost())

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

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

From aghaisas at openjdk.java.net  Tue Jun  8 07:22:48 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 8 Jun 2021 07:22:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F [v3]
In-Reply-To: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
Message-ID: <pmqdaeg0AW9g8I8Odf2yTLuuXQNnQPPR_OLWLnoNWXg=.26a8d00b-3d94-4b36-96ee-20bc3c959b47@github.com>

> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
> 
> **Issue :**
> SwingSet2 Demo - As reported in JBS description
> J2DDemo - As reported in a comment on JBS
> 
> **Root Cause :** 
> DrawPixel path is used only with uiScale=1.0. 
> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
> As mentioned in the documentation -
> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
> 
> "The vertex shader must provide [[point_size]], or the point size is undefined."
> 
> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
> 
> **Solution :**
>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  fix review comment on test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4356/files
  - new: https://git.openjdk.java.net/jdk/pull/4356/files/751c85cf..714fe22a

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

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

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

From psadhukhan at openjdk.java.net  Tue Jun  8 07:33:18 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 8 Jun 2021 07:33:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F [v3]
In-Reply-To: <pmqdaeg0AW9g8I8Odf2yTLuuXQNnQPPR_OLWLnoNWXg=.26a8d00b-3d94-4b36-96ee-20bc3c959b47@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
 <pmqdaeg0AW9g8I8Odf2yTLuuXQNnQPPR_OLWLnoNWXg=.26a8d00b-3d94-4b36-96ee-20bc3c959b47@github.com>
Message-ID: <Fa3llmg3fqn9EKROeC7ICLQQE2TOCaybmAOYDL-QR5E=.d3a1d88f-9f34-424c-86bc-5aaa44a350ad@github.com>

On Tue, 8 Jun 2021 07:22:48 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
>> 
>> **Issue :**
>> SwingSet2 Demo - As reported in JBS description
>> J2DDemo - As reported in a comment on JBS
>> 
>> **Root Cause :** 
>> DrawPixel path is used only with uiScale=1.0. 
>> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
>> As mentioned in the documentation -
>> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
>> 
>> "The vertex shader must provide [[point_size]], or the point size is undefined."
>> 
>> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
>> 
>> **Solution :**
>>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comment on test

test/jdk/java/awt/Graphics/DrawOvalTest.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @key headful

I feel there's nop need to have headful tag for this test as there is no frame being made visible, all rendering are into volatileimage

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

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

From aghaisas at openjdk.java.net  Tue Jun  8 09:37:16 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 8 Jun 2021 09:37:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F [v3]
In-Reply-To: <Fa3llmg3fqn9EKROeC7ICLQQE2TOCaybmAOYDL-QR5E=.d3a1d88f-9f34-424c-86bc-5aaa44a350ad@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
 <pmqdaeg0AW9g8I8Odf2yTLuuXQNnQPPR_OLWLnoNWXg=.26a8d00b-3d94-4b36-96ee-20bc3c959b47@github.com>
 <Fa3llmg3fqn9EKROeC7ICLQQE2TOCaybmAOYDL-QR5E=.d3a1d88f-9f34-424c-86bc-5aaa44a350ad@github.com>
Message-ID: <zbYsXmf4E6NvY-xud141G1GD_AcMm8JeMCfQ1FMer1I=.2b9bcf41-9b1a-4024-8708-32a26f8c3c2d@github.com>

On Tue, 8 Jun 2021 07:30:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix review comment on test
>
> test/jdk/java/awt/Graphics/DrawOvalTest.java line 26:
> 
>> 24: /**
>> 25:  * @test
>> 26:  * @key headful
> 
> I feel there's nop need to have headful tag for this test as there is no frame being made visible, all rendering are into volatileimage

There is a call to `getDefaultScreenDevice()` in test that throws `java.awt.HeadlessException` if the test is not marked as headful. Request you to file a follow-on bug if the test can be modified to make it headless.

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

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

From aghaisas at openjdk.java.net  Tue Jun  8 09:49:21 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 8 Jun 2021 09:49:21 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8266159: macOS ARM + Metal pipeline
 shows artifacts on Swing Menu with Java L&F
In-Reply-To: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
Message-ID: <Mq-LLun_neyyskz6BX8cDj_GCmV2Mcsp6jTd8xv6LL0=.6a6a1be8-4b76-4e95-b08b-231969438d1f@github.com>

On Fri, 4 Jun 2021 11:14:46 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR fixes an issue exclusively seen on Apple M1 systems when SwingSet2 demo is run with uiScale=1.0.
> 
> **Issue :**
> SwingSet2 Demo - As reported in JBS description
> J2DDemo - As reported in a comment on JBS
> 
> **Root Cause :** 
> DrawPixel path is used only with uiScale=1.0. 
> MTLPrimitiveTypePoint is used to draw a pixel while encoding a render command.
> As mentioned in the documentation -
> https://developer.apple.com/documentation/metal/mtlprimitivetype/mtlprimitivetypepoint?language=objc
> 
> "The vertex shader must provide [[point_size]], or the point size is undefined."
> 
> In our shader functions, we do not define this point size. It is harmless on x86_64 based mac systems, but causes visual artifacts on M1 mac systems.
> 
> **Solution :**
>  Explicitly define point size in shader functions that draw MTLPrimitiveTypePoint.

This pull request has now been integrated.

Changeset: 89da2021
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/89da2021ee194efd70f367f8fec16994335c38aa
Stats:     103 lines in 2 files changed: 103 ins; 0 del; 0 mod

8266159: macOS ARM + Metal pipeline shows artifacts on Swing Menu with Java L&F

Reviewed-by: jdv, prr

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

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

From prr at openjdk.java.net  Tue Jun  8 14:58:20 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 8 Jun 2021 14:58:20 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8266159: macOS ARM + Metal pipeline shows
 artifacts on Swing Menu with Java L&F [v3]
In-Reply-To: <zbYsXmf4E6NvY-xud141G1GD_AcMm8JeMCfQ1FMer1I=.2b9bcf41-9b1a-4024-8708-32a26f8c3c2d@github.com>
References: <1K8egi06wrGWmnBB_rW6H5wODLOIH1hrl5Ld6pSEsU8=.3b3fe12c-2c6b-4a8a-b172-2958d304507b@github.com>
 <pmqdaeg0AW9g8I8Odf2yTLuuXQNnQPPR_OLWLnoNWXg=.26a8d00b-3d94-4b36-96ee-20bc3c959b47@github.com>
 <Fa3llmg3fqn9EKROeC7ICLQQE2TOCaybmAOYDL-QR5E=.d3a1d88f-9f34-424c-86bc-5aaa44a350ad@github.com>
 <zbYsXmf4E6NvY-xud141G1GD_AcMm8JeMCfQ1FMer1I=.2b9bcf41-9b1a-4024-8708-32a26f8c3c2d@github.com>
Message-ID: <p8zsVrjPpDpyvgCwUv5lgCLt3AN0Ngu7xDACV3vrvGs=.5824732a-e67b-4c1b-a3c5-8d4900ba7fc9@github.com>

On Tue, 8 Jun 2021 09:34:38 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> test/jdk/java/awt/Graphics/DrawOvalTest.java line 26:
>> 
>>> 24: /**
>>> 25:  * @test
>>> 26:  * @key headful
>> 
>> I feel there's nop need to have headful tag for this test as there is no frame being made visible, all rendering are into volatileimage
>
> There is a call to `getDefaultScreenDevice()` in test that throws `java.awt.HeadlessException` if the test is not marked as headful. Request you to file a follow-on bug if the test can be modified to make it headless.

No, leave it headful.Headless would (should) not use Metal or OpenGL.
it would be all software loops.
If we are enabling metal or opengl in headless mode then that itself is a bug.

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

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

From prr at openjdk.java.net  Tue Jun  8 20:06:16 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 8 Jun 2021 20:06:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v2]
In-Reply-To: <fjeuy0xRFk1s8x157Xllfq1VRdlLOGN79q6A23zw4Kc=.2b3e3432-72e7-493f-96e1-b56c2b537cce@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <fjeuy0xRFk1s8x157Xllfq1VRdlLOGN79q6A23zw4Kc=.2b3e3432-72e7-493f-96e1-b56c2b537cce@github.com>
Message-ID: <OahTIOcOD21-F-gP2Y_1T_g8u6WciBbm_1NhT0ijHwY=.2629025c-8661-4bb7-a3e0-cc655d814212@github.com>

On Fri, 21 May 2021 20:16:41 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
>> 
>> ROOT CAUSE OF THE BUG:
>> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
>> 
>> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
>> 
>> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
>> 
>> THE FIX:
>> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
>> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
>> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
>> 
>> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second version of the fix

The points I have been trying to make are that
1) We need to make sure that important cleanup happens rather than just bailing
2) Despite Windows + Linux propagating a RTE, I am not sure this is what we want.
   If the RTE is something the *app* decides to throw,  then that's one thing but
   if something went wrong in the bowels of printing the spec says it should be a PrinterException.
   At the very least we should make sure temp files are deleted, any open calls
   to startDoc have been matched with a close ..

Hence my early comment "The exception should not propagate. State may need to be cleaned up. 
If you do anything you would make it the init cause of the PrinterException."
That means if we see an RTE propagated .. that could be a bug.

So I am nor comfortable just "aligning" the behaviour with WIndows and Linux without being
sure they are correct.

In other words, mac was probably catching this to do the clean up part, and that was likely OK
But yes, it probably was wrong not to rethrow as a wrapped (if needed) PrinterException

But although it opens a whole new can of worms I was suggesting you needed to look closely
at windows + linux and not just create a test which verified behaviour I am not sure we want.

I questioned the test etc about RTE because although it is good to test hrowing RTE  you
are verifying it ARRIVES still as an RTE, and I think it should be a PrinterException.

I am open to discussion about why this may be "actually OK" but it has to be better than
"the others are doing it" and it definitely should not be a reason to leave open files/jobs.

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

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

From prr at openjdk.java.net  Tue Jun  8 20:06:17 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 8 Jun 2021 20:06:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v2]
In-Reply-To: <NRjNLmrJjLMnm32ZQBF1cYik3PM1Y5aWSGdHpCyeKEg=.8ec0fee7-b61c-46cc-9044-dd3fcdd91a7a@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <fjeuy0xRFk1s8x157Xllfq1VRdlLOGN79q6A23zw4Kc=.2b3e3432-72e7-493f-96e1-b56c2b537cce@github.com>
 <O7asXz-60_EMTgNBs3i0glK9DNspl7rOXvJTFbAdtY8=.5dc03be2-e8c0-43cc-b220-75c07cecd113@github.com>
 <NRjNLmrJjLMnm32ZQBF1cYik3PM1Y5aWSGdHpCyeKEg=.8ec0fee7-b61c-46cc-9044-dd3fcdd91a7a@github.com>
Message-ID: <Rg3B_SV8YlUfJlxtkaVWaIxNW6FWJ8ir4j4Y_LjWX7M=.a44358ab-1d80-44f6-97b5-8ca4cf909efb@github.com>

On Mon, 31 May 2021 12:21:59 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java line 32:
>> 
>>> 30:    @run main/manual ExceptionFromPrintableIsIgnoredTest MAIN RE
>>> 31:    @run main/manual ExceptionFromPrintableIsIgnoredTest EDT PE
>>> 32:    @run main/manual ExceptionFromPrintableIsIgnoredTest EDT RE
>> 
>> wjy is this still manual ?
>
> The test is manual, because the test initiates printing and there is a chance that on a test host a default printer will be some virtual printer which can show the native dialog asking to specify the location of PDF file in which the printed document should be saved, in this case the test will be blocked and will be killed by "jtreg" by a timeout, what is unacceptable for the automatic test which should not slow down the speed of execution of all other automatic tests. For example such a virtual printer on Windows OS can be "Microsoft Print to PDF". By the way, I already explained this reason in one of my replies to your questions in the previous iteration of the code review.

I thought I also explained that the printer keyword means it would only be run if the system has a real printer by virtue of it being set in the jtreg run. You could also do that on a virtual printer if you didn't mind entering the file name

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

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

From alitvinov at openjdk.java.net  Wed Jun  9 21:22:55 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 9 Jun 2021 21:22:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v3]
In-Reply-To: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
Message-ID: <qcYyd_OEGPole0qW4lKh7rOqHdOmPHyN9p910xkfnfg=.f4010776-67aa-4bc1-b5f0-a26c6709d000@github.com>

> Hello,
> 
> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
> 
> ROOT CAUSE OF THE BUG:
> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
> 
> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
> 
> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
> 
> THE FIX:
> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
> 
> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
> 
> Thank you,
> Anton

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

 - Merge remote-tracking branch 'origin/master' into JDK-8262731
 - Second version of the fix
 - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4036/files
  - new: https://git.openjdk.java.net/jdk/pull/4036/files/47051517..746dc0c3

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

  Stats: 582865 lines in 4738 files changed: 500326 ins; 67543 del; 14996 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4036.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4036/head:pull/4036

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

From alitvinov at openjdk.java.net  Fri Jun 11 17:06:24 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Fri, 11 Jun 2021 17:06:24 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v4]
In-Reply-To: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
Message-ID: <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>

> Hello,
> 
> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
> 
> ROOT CAUSE OF THE BUG:
> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
> 
> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
> 
> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
> 
> THE FIX:
> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
> 
> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
> 
> Thank you,
> Anton

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

  Third version of the fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4036/files
  - new: https://git.openjdk.java.net/jdk/pull/4036/files/746dc0c3..056734b7

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

  Stats: 42 lines in 2 files changed: 19 ins; 16 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4036.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4036/head:pull/4036

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

From alitvinov at openjdk.java.net  Fri Jun 11 18:09:51 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Fri, 11 Jun 2021 18:09:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v4]
In-Reply-To: <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
Message-ID: <cptIrfZesP5BnQwbKGGXDrG9oy0FS0xRZ9587q73-8I=.f2e9f528-39c2-4c08-aba6-4d6545d73b64@github.com>

On Fri, 11 Jun 2021 17:06:24 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
>> 
>> ROOT CAUSE OF THE BUG:
>> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
>> 
>> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
>> 
>> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
>> 
>> THE FIX:
>> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
>> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
>> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
>> 
>> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Third version of the fix

Hello Phil,

I created the 3rd version of the fix which should address your remarks about the fix and the regression test. Can you please review the 3rd version of the fix (Webrev 03).

Thank you for provision with your position about different aspects of the fix, regression test and the discovered discrepancies with the specification on Windows OS and Linux OS. I absolutely agree that it is incorrect to implement propagation of RTE through "PrinterJob.print()" without wrapping it into "PrinterException", because RTE is not mentioned in the specification for "PrinterJob.print()" method. The 3rd fix version addresses this mistake from previous fix versions.

Perhaps, it is not very significant issue, that on Windows OS and Linux OS RTE from "Printable.print?(Graphics, PageFormat, int)" is propagated, because in this case the user's code does not follow the specification by throwing RTE from "Printable.print?(Graphics, PageFormat, int)". I do not want to investigate this discovered discrepancy with specification on Windows OS and Linux OS in this fix for a little different issue specific to macOS. If it is currently really necessary I can file a bug or 2 bugs in JBS to address the discovered issue on Windows and Linux.

Thank you for giving me the details about "printer" value for "@key" tag in "jtreg" test, because until that moment I mistakenly thought that it was just a marker used for selection of tests marked with it for running and nothing else.

DIFFERENCES INTRODUCED IN THE 3'RD VERSION OF THE FIX:

THE FIX:
1. "RuntimeException" is wrapped in new "PrinterException" in "CPrinterJob.print(PrintRequestAttributeSet)" to guarantee that the fix can propagate only "PrinterException" from "PrinterJob.print()".

THE REGRESSION TEST:
1. The test is now fully automatic, "manual" is removed from all JTREG "main" actions. I verified it on MACH and locally.

2. I addressed your concerns from previous comments and now no exception is thrown from "ExceptionFromPrintableIsIgnoredTest.runTest" method, so there is no any possibility that AWT thread will be crashed by the exception thrown by the test. Now I just execute "PrinterJob.print()" and store any "Throwable" possibly thrown by that method in the instance variable "private volatile Throwable printError" of the test class. And analyze it always on main thread after completion of execution of "ExceptionFromPrintableIsIgnoredTest.runTest" call.

3. Now the regression test always expects only "PrinterException" to be thrown by "PrinterJob.print()". Since "RuntimeException" is propagated from "PrinterJob.print()" on Windows OS and on Linux OS two test scenarios with "RuntimeException":
- "@run main ExceptionFromPrintableIsIgnoredTest MAIN RE"
- "@run main ExceptionFromPrintableIsIgnoredTest EDT RE"

are not executed by the test on Windows and Linux deliberately, otherwise they are failing. This test restriction is implemented by the "if" condition "if ((exceptionType == TestExceptionType.RE) && !isOSX) {".

Hopefully this version of the fix is more acceptable.

Thank you,
Anton

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

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

From prr at openjdk.java.net  Fri Jun 11 19:49:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 11 Jun 2021 19:49:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v4]
In-Reply-To: <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
Message-ID: <Hq8IfS5pQzDDvvY3wgaS9oL1ZahAxjq3DkhfLoWnPoM=.bd72512d-e4d3-4634-b07b-93d50c825069@github.com>

On Fri, 11 Jun 2021 17:06:24 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
>> 
>> ROOT CAUSE OF THE BUG:
>> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
>> 
>> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
>> 
>> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
>> 
>> THE FIX:
>> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
>> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
>> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
>> 
>> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Third version of the fix

Ok. Please file a bug as you mention to bring the other platforms into line.

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

Marked as reviewed by prr (Reviewer).

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

From alitvinov at openjdk.java.net  Mon Jun 14 13:13:50 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Mon, 14 Jun 2021 13:13:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print" [v4]
In-Reply-To: <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
 <D9t5V_tZKDfLPDXEubCRguAPpteUhpF1x1Q_sDmb3io=.13e18b5a-c365-46ef-b38a-451bc207ade8@github.com>
Message-ID: <Y7cMBO-NtewjxMkh6NGvedbOULhmz6WUM6ltUC4YNMQ=.65cd67f8-a4cd-4bc5-a9ea-93f7d0dce4cf@github.com>

On Fri, 11 Jun 2021 17:06:24 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

>> Hello,
>> 
>> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
>> 
>> ROOT CAUSE OF THE BUG:
>> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
>> 
>> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
>> 
>> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
>> 
>> THE FIX:
>> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
>> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
>> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
>> 
>> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
>> 
>> Thank you,
>> Anton
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Third version of the fix

Hello Phil. Thank you for approval of the fix. The new bug about the discovered propagation of the RTE on Windows OS and Linux OS is created, it is (https://bugs.openjdk.java.net/browse/JDK-8268675).

Thank you,
Anton

________________________________________
From: prrace ***@***.***>
Sent: 11 June 2021 20:47
To: openjdk/jdk
Cc: Anton Litvinov; Mention
Subject: [External] : Re: [openjdk/jdk] 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" (#4036)

@prrace approved this pull request.

Ok. Please file a bug as you mention to bring the other platforms into line.

?
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/4036*pullrequestreview-682168475__;Iw!!GqivPVa7Brio!O44TB5FBjFmxmBOMWJaShp0YE2GnSsoKioCVpjjeiWAFttaxMCzjTqiQ8X7BFHWNytY$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AQY7S7FDBITH5EYGP42RUTLTSJR5XANCNFSM44443KWA__;!!GqivPVa7Brio!O44TB5FBjFmxmBOMWJaShp0YE2GnSsoKioCVpjjeiWAFttaxMCzjTqiQ8X7BFC_1zPk$>.

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

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

From alitvinov at openjdk.java.net  Mon Jun 14 13:32:14 2021
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Mon, 14 Jun 2021 13:32:14 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8262731: [macOS] Exception from
 "Printable.print" is swallowed during "PrinterJob.print"
In-Reply-To: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
References: <WtvTpphLzcVdpBkmFv8MDcklY8SIMqbeRKz6Q63GnaA=.2e8c9ffd-d6ad-4f07-b651-4fb529e15067@github.com>
Message-ID: <wTM7hzTJPQSCaLBssMow8o6ZP1negBNqKQZOAdRxQhE=.2f2573e5-3126-4a80-8ba8-99a74c55d440@github.com>

On Fri, 14 May 2021 18:37:46 GMT, Anton Litvinov <alitvinov at openjdk.org> wrote:

> Hello,
> 
> Could you please review the following fix for the bug specific to macOS. The bug consists in the fact that if the method "java.awt.print.Printable.print?(Graphics, PageFormat, int)" throws "java.awt.print.PrinterException" or "java.lang.RuntimeException" during the call "java.awt.print.PrinterJob.print()", then the exception is caught and ignored by JDK and a user cannot learn that printing failed and what caused failure of printing, because "PrinterJob.print()" method does not throw "PrinterException" or the occurred exception is not reported by JDK through the error stream.
> 
> ROOT CAUSE OF THE BUG:
> The root cause of the bug is the fact that in the method "sun.lwawt.macosx.CPrinterJob.printAndGetPageFormatArea(final Printable, final Graphics, final PageFormat, final int)" from the file "src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java" the exception thrown during execution of the expression
> 
> "int pageResult = printable.print(graphics, pageFormat, pageIndex);"
> 
> is caught but is not returned to a developer by any mean or is not printed out to the error stream.
> 
> THE FIX:
> The fix implements propagation of the occurred and caught exception to the level of the user's code executing "PrinterJob.print()" method. Propagation of the exception by storing it in the instance variable of "CPrinterJob" object is implemented, because the engaged code always is executed:
> - on 2 threads (non-EDT thread, EDT thread) in case when "PrinterJob.print()" is called by the user on a non-EDT thread;
> - on 3 threads (2 EDT threads, a temporary thread started by JDK to execute "CPrinterJob._safePrintLoop(long, long );") when "PrinterJob.print()" is called on EDT thread.
> 
> The regression test which is part of the fix was also successfully executed on MS Windows OS and Linux OS.
> 
> Thank you,
> Anton

This pull request has now been integrated.

Changeset: c0b4407d
Author:    Anton Litvinov <alitvinov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0b4407d09a7bf9f15553dc5344b1e354b150d57
Stats:     169 lines in 2 files changed: 160 ins; 0 del; 9 mod

8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"

Reviewed-by: prr

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

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

From prr at openjdk.java.net  Mon Jun 14 19:29:53 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 14 Jun 2021 19:29:53 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8240756: [macos]
 SwingSet2:TableDemo:Printed Japanese characters were garbled
In-Reply-To: <8Q74yMehR_J-kCb_2YKa0jDPSuyq5km4bc1t-P7xL0o=.27738de9-2500-4b38-83ba-e6c55b9ac43b@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com>
 <8Q74yMehR_J-kCb_2YKa0jDPSuyq5km4bc1t-P7xL0o=.27738de9-2500-4b38-83ba-e6c55b9ac43b@github.com>
Message-ID: <ejcxE5myl4nS0I5kdm3oNLTGD3w66DaSQ9ExwuZsbLw=.b69dd1e0-94b0-44ba-ae72-09949df0777d@github.com>

On Fri, 23 Apr 2021 09:45:45 GMT, Toshio Nakamura <tnakamura at openjdk.org> wrote:

>> As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font?
>
>> As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font?
> 
> Hi Sergey, Thank you for the comments.
> 
> JTable is not directly related, but it has child JComponents under texts. It's the trigger to meet the conditions to call the function.
> 
> In this case, the font was specified as "LucidaGrande" or "Dialog" by L&F. Non English character to print is another condition.
> sun.font.CFont creates a composite font by the standard Mac cascade list. In my environment, font[4] is Japanese font, even if it's CFont("LucidaGrande").
> 
> CTextPipe.doDrawGlyphs uses one strike pointer, which is for one font. To support composite fonts, I think CTextPipe needs to handle array of strikes, and to switch fonts by slot data. I don't think this is a right way.
> 
> CTextPipe.drawGlyphVector receives only GlyphVector data and no Unicode character data. So, we cannot use fallback methods.

@toshiona - is this PR dead ?

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Tue Jun 15 12:22:50 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 15 Jun 2021 12:22:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8268764: Use Long.hashCode() instead of
 int-cast where applicable
Message-ID: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>

In some JDK classes there's still the following hashCode() implementation:

long objNum;

public int hashCode() {
    return (int) objNum;
}

This outdated expression should be replaced with Long.hashCode(long) as it

- uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).

- does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.

See https://stackoverflow.com/a/4045083

This is related to https://github.com/openjdk/jdk/pull/4309

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

Commit messages:
 - 8268764: Use Long.hashCode() instead of int-cast where applicable

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

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

From avu at openjdk.java.net  Tue Jun 15 17:03:02 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Tue, 15 Jun 2021 17:03:02 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite shows
 differences on Metal compared to OpenGL
Message-ID: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>

Implemented blit via compute kernel

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

Commit messages:
 - 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From serb at openjdk.java.net  Tue Jun 15 17:50:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 15 Jun 2021 17:50:43 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

Marked as reviewed by serb (Reviewer).

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159:

> 157:         [computeEncoder endEncoding];
> 158:         [cb commit];
> 159: #endif

This is better than changing the background color, but should be carefully checked. @jayathirthrao @aghaisas please take a look.
Since this affects every blit to the window I suggest running a full test run.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Wed Jun 16 10:37:31 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 16 Jun 2021 10:37:31 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
Message-ID: <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>

On Tue, 15 Jun 2021 17:47:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159:
> 
>> 157:         [computeEncoder endEncoding];
>> 158:         [cb commit];
>> 159: #endif
> 
> This is better than changing the background color, but should be carefully checked. @jayathirthrao @aghaisas please take a look.
> Since this affects every blit to the window I suggest running a full test run.

@jayathirthrao @aghaisas please let me know if I can push this change into JDK17 repository

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From jdv at openjdk.java.net  Wed Jun 16 11:59:34 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 16 Jun 2021 11:59:34 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
 <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
Message-ID: <Vq4jlYkcm5WjQaWCz6d_AQ5sT2VtduiPwf66qUG14Mg=.f82efbcf-18f7-47c6-ac13-b55c615b2930@github.com>

On Wed, 16 Jun 2021 10:34:50 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159:
>> 
>>> 157:         [computeEncoder endEncoding];
>>> 158:         [cb commit];
>>> 159: #endif
>> 
>> This is better than changing the background color, but should be carefully checked. @jayathirthrao @aghaisas please take a look.
>> Since this affects every blit to the window I suggest running a full test run.
>
> @jayathirthrao @aghaisas please let me know if I can push this change into JDK17 repository

@avu i have given all test run. I will get back to you once it is done.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From jdv at openjdk.java.net  Thu Jun 17 07:10:10 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 17 Jun 2021 07:10:10 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <byc4ARD0fgZRtxq6Q-nZFut5Cf3n8psNeN1Uskvov5E=.589e6f66-4bd4-4067-8f25-7093e7e04ae9@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 136:

> 134:         NSUInteger w = computePipelineState.threadExecutionWidth;
> 135: 
> 136:         // Workaround for some OS/device bug reporting incorrect maxTotalThreadsPerThreadgroup

@avu Do we know in which hardware we have this issue? Also do we have any reference to Apple bug?
Also if we use thread group as 1 what is the performance impact in such hardware?

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From jdv at openjdk.java.net  Thu Jun 17 07:15:12 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 17 Jun 2021 07:15:12 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <Vq4jlYkcm5WjQaWCz6d_AQ5sT2VtduiPwf66qUG14Mg=.f82efbcf-18f7-47c6-ac13-b55c615b2930@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
 <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
 <Vq4jlYkcm5WjQaWCz6d_AQ5sT2VtduiPwf66qUG14Mg=.f82efbcf-18f7-47c6-ac13-b55c615b2930@github.com>
Message-ID: <L6wARnjCs-1NRUPoEbMw54Ab8HOPY0iV3v3XV5lRmpk=.44f47b2a-76d2-450a-892d-a5d43052fb1e@github.com>

On Wed, 16 Jun 2021 11:57:01 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> @jayathirthrao @aghaisas please let me know if I can push this change into JDK17 repository
>
> @avu i have given all test run. I will get back to you once it is done.

Automated jtreg/JCK test run is green.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From tnakamura at openjdk.java.net  Thu Jun 17 09:29:07 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 17 Jun 2021 09:29:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8240756: [macos]
 SwingSet2:TableDemo:Printed Japanese characters were garbled [v2]
In-Reply-To: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
Message-ID: <gSWVk7c86gLoQBXz4BUgx_lBDXMlpcX52cte4mf96ss=.134edd2c-4630-4df4-b0e3-ba1d31328a1c@github.com>

> Hi,
> 
> Could you review the fix?
> When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts.
> 
> The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn. 
> 
> This patch checks slot data of each character. If slot data exists, it will branch to GlyphVector's drawing path.
> 
> Well, I couldn't create automatic test for this fix. This method seems to be called for printing only. I appreciate any advice.
> Tested java/awt and javax/swing on MacOS BigSur, and there was no regression.
> 
> Regards,
> Toshio Nakamura

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

 - 2nd proposal
 - Revert previous change
 - Merge branch 'master' into 8240756
   merge master
 - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3619/files
  - new: https://git.openjdk.java.net/jdk/pull/3619/files/9d99458c..c2910791

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

  Stats: 1152276 lines in 9449 files changed: 556262 ins; 566916 del; 29098 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3619.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619

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

From tnakamura at openjdk.java.net  Thu Jun 17 09:29:08 2021
From: tnakamura at openjdk.java.net (Toshio Nakamura)
Date: Thu, 17 Jun 2021 09:29:08 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8240756: [macos]
 SwingSet2:TableDemo:Printed Japanese characters were garbled
In-Reply-To: <ejcxE5myl4nS0I5kdm3oNLTGD3w66DaSQ9ExwuZsbLw=.b69dd1e0-94b0-44ba-ae72-09949df0777d@github.com>
References: <JM1ajWFlO67nrSxj3JOiLZ1h4l-IVFkZVI1kf4nd3vo=.cae6dc96-15a2-4856-a2b9-352492a41bbb@github.com>
 <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com>
 <8Q74yMehR_J-kCb_2YKa0jDPSuyq5km4bc1t-P7xL0o=.27738de9-2500-4b38-83ba-e6c55b9ac43b@github.com>
 <ejcxE5myl4nS0I5kdm3oNLTGD3w66DaSQ9ExwuZsbLw=.b69dd1e0-94b0-44ba-ae72-09949df0777d@github.com>
Message-ID: <ggQJztCX7uUW2RXvz_c0B7OANyJMn_FHCHjnEwbq7Yo=.bc94ec7c-2d94-4031-b13b-3c2f0542894d@github.com>

On Mon, 14 Jun 2021 19:26:46 GMT, Phil Race <prr at openjdk.org> wrote:

>>> As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font?
>> 
>> Hi Sergey, Thank you for the comments.
>> 
>> JTable is not directly related, but it has child JComponents under texts. It's the trigger to meet the conditions to call the function.
>> 
>> In this case, the font was specified as "LucidaGrande" or "Dialog" by L&F. Non English character to print is another condition.
>> sun.font.CFont creates a composite font by the standard Mac cascade list. In my environment, font[4] is Japanese font, even if it's CFont("LucidaGrande").
>> 
>> CTextPipe.doDrawGlyphs uses one strike pointer, which is for one font. To support composite fonts, I think CTextPipe needs to handle array of strikes, and to switch fonts by slot data. I don't think this is a right way.
>> 
>> CTextPipe.drawGlyphVector receives only GlyphVector data and no Unicode character data. So, we cannot use fallback methods.
>
> @toshiona - is this PR dead ?

@prrace 
I'm deeply sorry for the long delay.
I completely changed the patch to use a different layer (SwingUtilities2.java).

> The immediately next method in this file, drawGlyphVector(..) surely would have the same problem ?

Yes, I had to say the bottom methods (Core Graphics Framework's CGContextShowGlyphsWithAdvances and CGContextShowGlyphsAtPoint) seem no capability to handle multi fonts.

> And then the drawChars method too ?

No. If we can use Unicode codes, fallback mechanism can work.

> Does this not in fact affect all code points for which the slot != 0 ?

Yes. I believe all slot !=0 glyphs have the issue.

> Do we really want to print all code points from slot > 0 as shapes ? 

No, it's a kind of workaround. I thought the effects of the change can be minimized.

> And if this code isn't expecting to handle composite fonts, how did we get here with one ?
> Or maybe the problem is that the printing path code needs to handle this downstream not upstream ?

The new version changed the branching conditions. If it's MacOS, that won't branch to the printing path, which uses Glyph codes.

Well, I still couldn't create an automate test.

I appreciate any advices.

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

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

From jdv at openjdk.java.net  Thu Jun 17 09:44:14 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 17 Jun 2021 09:44:14 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <byc4ARD0fgZRtxq6Q-nZFut5Cf3n8psNeN1Uskvov5E=.589e6f66-4bd4-4067-8f25-7093e7e04ae9@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <byc4ARD0fgZRtxq6Q-nZFut5Cf3n8psNeN1Uskvov5E=.589e6f66-4bd4-4067-8f25-7093e7e04ae9@github.com>
Message-ID: <VHriLswBqHagFxgiPOv22RexH1Xf4AMUe7K55dCx_-s=.021519f6-1622-46cc-b9b8-ce4802c6095d@github.com>

On Thu, 17 Jun 2021 07:06:24 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 136:
> 
>> 134:         NSUInteger w = computePipelineState.threadExecutionWidth;
>> 135: 
>> 136:         // Workaround for some OS/device bug reporting incorrect maxTotalThreadsPerThreadgroup
> 
> @avu Do we know in which hardware we have this issue? Also do we have any reference to Apple bug?
> Also if we use thread group as 1 what is the performance impact in such hardware?

Forced maxTotalThreadsPerThreadgroup to 1 and tested in Intel SoC 2015 Macbook Pro, as expected i see almost ~50% reduction in FPS numbers in many use cases in RenderPerfTest. This final blit hits common operation and we would be able to make better decision whether this performance reduction is okay or not based on hardware in which we are seeing Apple bug.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From jdv at openjdk.java.net  Thu Jun 17 10:21:09 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 17 Jun 2021 10:21:09 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <bA2208vnJVqsnRNOJgNlaL_-9TqHO1faPe36byX-h28=.8d268720-4493-42c4-8415-e715cc4a98ee@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

With this patch shaped windows with translucent/color background are showing only black background. In manual JCK shaped window test also this difference in behaviour is seen.

This behaviour difference can be checked using Ruler.java test case attached in https://bugs.openjdk.java.net/browse/JDK-8267963

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From aghaisas at openjdk.java.net  Thu Jun 17 11:30:12 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 17 Jun 2021 11:30:12 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <SuL-tRkrTJOgpmcUgoVjLS6lsYFjG9CviTGsHj2kFa4=.4cae3fe0-9992-47fe-ae8e-ecd12838beb6@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

What I have observed with this patch is - It does not break all shaped or translucent windows - but, a manual JCK test does show the black background.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From serb at openjdk.java.net  Thu Jun 17 13:00:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 17 Jun 2021 13:00:11 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <fmrLhYGENAO-tYTY7qT0ijL5dIASeaBsBw8y_zKCZGY=.f95f9a14-bf6f-4545-abb2-d8e24076c6ef@github.com>
 <mSTaVD1VtcLUFD7dmtJdWQOBRw1rs0Plg5POnzLoz_k=.f845086f-88e7-47e4-97c6-3a9cec88a6a3@github.com>
Message-ID: <RR4jJ7Q2sbfF6Rt8QpRu2_Akla5pfbozd0HeSVpV_tM=.c124052f-f409-458e-97ab-8c4d5bf9c7b7@github.com>

On Wed, 16 Jun 2021 10:34:50 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 159:
>> 
>>> 157:         [computeEncoder endEncoding];
>>> 158:         [cb commit];
>>> 159: #endif
>> 
>> This is better than changing the background color, but should be carefully checked. @jayathirthrao @aghaisas please take a look.
>> Since this affects every blit to the window I suggest running a full test run.
>
> @jayathirthrao @aghaisas please let me know if I can push this change into JDK17 repository

@avu If all our automated tests are green but we still have some issues, then an additional automated test needs to be added.

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From avu at openjdk.java.net  Mon Jun 21 18:00:37 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Mon, 21 Jun 2021 18:00:37 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <j0N0mujnw8_9jyBo59F1JRcDmlv1nhMQqb42Ne53Rf0=.0542ca07-75cb-4c5e-a368-1e046f4ebfdb@github.com>

On Tue, 15 Jun 2021 16:57:00 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Implemented blit via compute kernel

Just found the more simple solution to this problem: we can still use old blit code and keep MTLLayer opacity property in sync with contentView of the window (CWraper.setOpaque).

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From github.com+28651297+mkartashev at openjdk.java.net  Wed Jun 23 09:28:45 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Wed, 23 Jun 2021 09:28:45 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working with
 fonts on Linux
Message-ID: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>

Added an `ExceptionCheck()` followed by `ExceptionDescribe()` and `ExceptionClear()` immediately after the Java calls made from the callback function `ReadTTFontFileFunc()` in `freetypeScaler.c`. 

The exception(s) need to be cleared because we're not returning immediately to Java that would've been able to handle them gracefully. And in order not to loose the exception entirely (even though the return value would also indicate an error condition), print out the exception with `ExceptionDescribe()` to aid in debugging.

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

Commit messages:
 - 8269223: -Xcheck:jni WARNINGs working with fonts on Linux

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

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

From avu at openjdk.java.net  Wed Jun 23 12:15:03 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Wed, 23 Jun 2021 12:15:03 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v2]
In-Reply-To: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
Message-ID: <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>

> Implemented blit via compute kernel

Alexey Ushakov 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 one new commit since the last revision:

  8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
  
  Keep MTLLayer opacity in sync with window content view

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/62/files
  - new: https://git.openjdk.java.net/jdk17/pull/62/files/4d1b80ff..3eef431e

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

  Stats: 56 lines in 4 files changed: 4 ins; 50 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/62/head:pull/62

PR: https://git.openjdk.java.net/jdk17/pull/62

From serb at openjdk.java.net  Mon Jun 28 22:48:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 28 Jun 2021 22:48:05 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8266079: Lanai: AlphaComposite
 shows differences on Metal compared to OpenGL [v2]
In-Reply-To: <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
References: <a3xpk6ClZB2__CikIXazTo8cnlVr_ppS03q66O36uu8=.3cf9bb53-ddbf-40cf-8b1c-74a150945d89@github.com>
 <uLTCX_HaIt0PVRv4psEvWUaVD6JevtuQ4puSuQaA8Q8=.df26bb2b-18bb-4952-8465-d7ec21aa8dd2@github.com>
Message-ID: <_ckINhzlkfObwA0ncLZCaoFzWItgZUyR-4Bg3evQYME=.890f1ed7-d977-4f2a-9125-3a0fef580440@github.com>

On Wed, 23 Jun 2021 12:15:03 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Implemented blit via compute kernel
>
> Alexey Ushakov 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 one new commit since the last revision:
> 
>   8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL
>   
>   Keep MTLLayer opacity in sync with window content view

src/java.desktop/macosx/native/libawt_lwawt/awt/CWrapper.m line 349:

> 347:         if ([window.contentView.layer isKindOfClass:[CAMetalLayer class]]) {
> 348:             [window.contentView.layer setOpaque:(BOOL)opaque];
> 349:         }

This class "CWrapper" is intended to be a simple wrapper on top of cocoa methods, the changed method above is expected to call the "NSWindow#setOpaque" only. So you need to place "window.contentView.layer setOpaque" in some other place(native or java).

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

PR: https://git.openjdk.java.net/jdk17/pull/62

From jdv at openjdk.java.net  Tue Jun 29 17:39:26 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 29 Jun 2021 17:39:26 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
Message-ID: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>

Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().

Sanity and performance analysis is green. More details in JBS.

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

Commit messages:
 - 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From serb at openjdk.java.net  Tue Jun 29 23:30:04 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Jun 2021 23:30:04 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux
In-Reply-To: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
Message-ID: <NFFyA8m_x4iByCkTACJgZM03HzFiiuS6wsMhN_vOhrc=.ab61fb15-6a11-4dcd-8b62-c15f96d9f87b@github.com>

On Wed, 23 Jun 2021 09:19:16 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

> Added an `ExceptionCheck()` followed by `ExceptionDescribe()` and `ExceptionClear()` immediately after the Java calls made from the callback function `ReadTTFontFileFunc()` in `freetypeScaler.c`. 
> 
> The exception(s) need to be cleared because we're not returning immediately to Java that would've been able to handle them gracefully. And in order not to loose the exception entirely (even though the return value would also indicate an error condition), print out the exception with `ExceptionDescribe()` to aid in debugging.

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 146:

> 144:     freeNativeResources(env, scalerInfo);
> 145:     (*env)->CallVoidMethod(env, scaler, invalidateScalerMID);
> 146:     // NB: Exceptions must not be cleared (and therefore no JNI calls performed) after calling this method

Please split long lines to 80 chars per line

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 199:

> 197:                                           bBuffer, offset, numBytes);
> 198:             // This is a callback, we are not returning immediately to Java and better report exceptions now
> 199:             CHECK_EXCEPTION(env);

Probably we should report it only if "debugFonts" was set?

test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java line 28:

> 26:  * @bug 8269223
> 27:  * @summary Verifies that -Xcheck:jni issues no warnings from freetypeScaler.c
> 28:  * @requires os.family == "linux"

Can we run this test on all platforms? Since this bug was not found, means we did not cover this code by the tests, and it will be useful to test it even if the code path will be different on other platforms.

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

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

From serb at openjdk.java.net  Tue Jun 29 23:34:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 29 Jun 2021 23:34:05 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
In-Reply-To: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
Message-ID: <wF9gDRlgIpJjivO3ioHEmS3TRGzHI6jCYx5ATbiAN30=.71b594b7-f06d-407c-976f-248996474d82@github.com>

On Tue, 29 Jun 2021 17:34:00 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
> In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().
> 
> Sanity and performance analysis is green. More details in JBS.

Please confirm that mach5 is green.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 286:

> 284:     if (layer == NULL || ctx == NULL) {
> 285:         J2dTraceLn(J2D_TRACE_VERBOSE, "MTLLayer_blit : Layer or Context is null");
> 286:         [layer stopDisplayLink];

What happens if we exit before this "blitTexture" is called? Do not we need to stop(w/o possibility to restart it) that thread on toolkit shutdown or something like this?

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From prr at openjdk.java.net  Wed Jun 30 00:12:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 30 Jun 2021 00:12:03 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux
In-Reply-To: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
Message-ID: <QRHoUfQjNsw564I45z6SgcYSBw7MzZ9g644W8G74OWY=.62b31f52-9918-4d57-a9ae-5ec60567270f@github.com>

On Wed, 23 Jun 2021 09:19:16 GMT, Maxim Kartashev <github.com+28651297+mkartashev at openjdk.org> wrote:

> Added an `ExceptionCheck()` followed by `ExceptionDescribe()` and `ExceptionClear()` immediately after the Java calls made from the callback function `ReadTTFontFileFunc()` in `freetypeScaler.c`. 
> 
> The exception(s) need to be cleared because we're not returning immediately to Java that would've been able to handle them gracefully. And in order not to loose the exception entirely (even though the return value would also indicate an error condition), print out the exception with `ExceptionDescribe()` to aid in debugging.

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 53:

> 51:         (*(env))->ExceptionDescribe(env);\
> 52:         (*(env))->ExceptionClear(env);   \
> 53:     }

https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#exceptiondescribe

"The pending exception is cleared as a side-effect of calling this function"

So you certainly don't need both of these and I would prefer that Describe only be used if really debugging where we think there's a REAL chance of an exception rather than just to keep JNI happy.

And the upcall that is likely (readBlock) itself will log any IOException (and catch it) in the event of an I/O error so I really think this is unlikely to be useful here.

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 198:

> 196:                                           sunFontIDs.ttReadBlockMID,
> 197:                                           bBuffer, offset, numBytes);
> 198:             // This is a callback, we are not returning immediately to Java and better report exceptions now

I think the comment is un-needed .. since the only reason to call CHECK_EXCEPTION() is because of this.
Same for the other case.

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

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

From jdv at openjdk.java.net  Wed Jun 30 04:03:59 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 30 Jun 2021 04:03:59 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
In-Reply-To: <wF9gDRlgIpJjivO3ioHEmS3TRGzHI6jCYx5ATbiAN30=.71b594b7-f06d-407c-976f-248996474d82@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <wF9gDRlgIpJjivO3ioHEmS3TRGzHI6jCYx5ATbiAN30=.71b594b7-f06d-407c-976f-248996474d82@github.com>
Message-ID: <_6cyIO31CYIYiDKnfk92G9Ktww461LZi-NJ2RSxil84=.2122489c-5d07-48ce-bf95-ecb8224a448b@github.com>

On Tue, 29 Jun 2021 23:31:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
>> In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().
>> 
>> Sanity and performance analysis is green. More details in JBS.
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 286:
> 
>> 284:     if (layer == NULL || ctx == NULL) {
>> 285:         J2dTraceLn(J2D_TRACE_VERBOSE, "MTLLayer_blit : Layer or Context is null");
>> 286:         [layer stopDisplayLink];
> 
> What happens if we exit before this "blitTexture" is called? Do not we need to stop(w/o possibility to restart it) that thread on toolkit shutdown or something like this?

At this point if we exit, we just return and unlock MTLRenderQueue for backbuffer rendering. And when it is done we again start CVDisplayLink in MTLRenderQueue which in turn calls setNeedsDisplay to get callback to MTLLayer.display().

This scenario is same as returning from CGLLayer.blitTexture() when textureID is 0. Appkit thread will be running in the background and we dont stop it.

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From serb at openjdk.java.net  Wed Jun 30 04:33:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Jun 2021 04:33:05 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
In-Reply-To: <_6cyIO31CYIYiDKnfk92G9Ktww461LZi-NJ2RSxil84=.2122489c-5d07-48ce-bf95-ecb8224a448b@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <wF9gDRlgIpJjivO3ioHEmS3TRGzHI6jCYx5ATbiAN30=.71b594b7-f06d-407c-976f-248996474d82@github.com>
 <_6cyIO31CYIYiDKnfk92G9Ktww461LZi-NJ2RSxil84=.2122489c-5d07-48ce-bf95-ecb8224a448b@github.com>
Message-ID: <YYWQOUp1bI3sCqvehkchKzjFaE0OkgsVsb3crrcoyRM=.e1f51fd6-7e29-470b-bb87-11c632a0b7da@github.com>

On Wed, 30 Jun 2021 04:00:54 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 286:
>> 
>>> 284:     if (layer == NULL || ctx == NULL) {
>>> 285:         J2dTraceLn(J2D_TRACE_VERBOSE, "MTLLayer_blit : Layer or Context is null");
>>> 286:         [layer stopDisplayLink];
>> 
>> What happens if we exit before this "blitTexture" is called? Do not we need to stop(w/o possibility to restart it) that thread on toolkit shutdown or something like this?
>
> At this point if we exit, we just return and unlock MTLRenderQueue for backbuffer rendering. And when it is done we again start CVDisplayLink in MTLRenderQueue which in turn calls setNeedsDisplay to get callback to MTLLayer.display().
> 
> This scenario is same as returning from CGLLayer.blitTexture() when textureID is 0. Appkit thread will be running in the background and we dont stop it.

No, I meant if we dispose the frame/exist from the app/etc before "Java_sun_java2d_metal_MTLLayer_blitTexture" method is executed but after we call "startDisplayLink", when we will call the stopDisplayLink in this case?

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From jdv at openjdk.java.net  Wed Jun 30 04:52:59 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 30 Jun 2021 04:52:59 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
In-Reply-To: <YYWQOUp1bI3sCqvehkchKzjFaE0OkgsVsb3crrcoyRM=.e1f51fd6-7e29-470b-bb87-11c632a0b7da@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <wF9gDRlgIpJjivO3ioHEmS3TRGzHI6jCYx5ATbiAN30=.71b594b7-f06d-407c-976f-248996474d82@github.com>
 <_6cyIO31CYIYiDKnfk92G9Ktww461LZi-NJ2RSxil84=.2122489c-5d07-48ce-bf95-ecb8224a448b@github.com>
 <YYWQOUp1bI3sCqvehkchKzjFaE0OkgsVsb3crrcoyRM=.e1f51fd6-7e29-470b-bb87-11c632a0b7da@github.com>
Message-ID: <Mc0TBFCmAPRsxC3f4KR9gnZZYjxteK4KH1AJl5buUJ0=.a5264ade-cf77-4ebd-97d6-1f22967fc10e@github.com>

On Wed, 30 Jun 2021 04:29:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> At this point if we exit, we just return and unlock MTLRenderQueue for backbuffer rendering. And when it is done we again start CVDisplayLink in MTLRenderQueue which in turn calls setNeedsDisplay to get callback to MTLLayer.display().
>> 
>> This scenario is same as returning from CGLLayer.blitTexture() when textureID is 0. Appkit thread will be running in the background and we dont stop it.
>
> No, I meant if we dispose the frame/exist from the app/etc before "Java_sun_java2d_metal_MTLLayer_blitTexture" method is executed but after we call "startDisplayLink", when we will call the stopDisplayLink in this case?

In that case it will hit MTLLayer.dealloc() where we stop and release CVDisplayLink.

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From jdv at openjdk.java.net  Wed Jun 30 08:12:03 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 30 Jun 2021 08:12:03 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
In-Reply-To: <YYWQOUp1bI3sCqvehkchKzjFaE0OkgsVsb3crrcoyRM=.e1f51fd6-7e29-470b-bb87-11c632a0b7da@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <wF9gDRlgIpJjivO3ioHEmS3TRGzHI6jCYx5ATbiAN30=.71b594b7-f06d-407c-976f-248996474d82@github.com>
 <_6cyIO31CYIYiDKnfk92G9Ktww461LZi-NJ2RSxil84=.2122489c-5d07-48ce-bf95-ecb8224a448b@github.com>
 <YYWQOUp1bI3sCqvehkchKzjFaE0OkgsVsb3crrcoyRM=.e1f51fd6-7e29-470b-bb87-11c632a0b7da@github.com>
Message-ID: <mfuoOWjJSGCs4Ev2gZKuCRStjbjTJPz8y8ikfLz4KCM=.0d239f63-0aba-4d62-ad38-56b0db1c2849@github.com>

On Wed, 30 Jun 2021 04:29:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> At this point if we exit, we just return and unlock MTLRenderQueue for backbuffer rendering. And when it is done we again start CVDisplayLink in MTLRenderQueue which in turn calls setNeedsDisplay to get callback to MTLLayer.display().
>> 
>> This scenario is same as returning from CGLLayer.blitTexture() when textureID is 0. Appkit thread will be running in the background and we dont stop it.
>
> No, I meant if we dispose the frame/exist from the app/etc before "Java_sun_java2d_metal_MTLLayer_blitTexture" method is executed but after we call "startDisplayLink", when we will call the stopDisplayLink in this case?

@mrserb Please let me know if i can resolve this conversation.

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From jdv at openjdk.java.net  Wed Jun 30 08:12:03 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 30 Jun 2021 08:12:03 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
In-Reply-To: <wF9gDRlgIpJjivO3ioHEmS3TRGzHI6jCYx5ATbiAN30=.71b594b7-f06d-407c-976f-248996474d82@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <wF9gDRlgIpJjivO3ioHEmS3TRGzHI6jCYx5ATbiAN30=.71b594b7-f06d-407c-976f-248996474d82@github.com>
Message-ID: <GxTQSxifirX-AHkGmxjtqIqWHwQDja-VFS2QAgzDeSU=.099083c9-38af-470e-bbbe-f047252452df@github.com>

On Tue, 29 Jun 2021 23:28:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please confirm that mach5 is green.

@mrserb Yes CI test run is green. Test link in JBS.

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From github.com+28651297+mkartashev at openjdk.java.net  Wed Jun 30 10:42:44 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Wed, 30 Jun 2021 10:42:44 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v2]
In-Reply-To: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
Message-ID: <8Rk4Vnlp_DCPQ8nocSevcUwS2QOUMfYsThZZAY4tL4Y=.a7cc56ae-b10a-4a79-b419-9e29273d51da@github.com>

> Added an `ExceptionCheck()` followed by `ExceptionDescribe()` and `ExceptionClear()` immediately after the Java calls made from the callback function `ReadTTFontFileFunc()` in `freetypeScaler.c`. 
> 
> The exception(s) need to be cleared because we're not returning immediately to Java that would've been able to handle them gracefully. And in order not to loose the exception entirely (even though the return value would also indicate an error condition), print out the exception with `ExceptionDescribe()` to aid in debugging.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  Addressed PR comments
  
  1. Allowed test to run on any platform.
  2. Trimmed comments to fit in with 80 columns.
  3. Removed unnecessayr comments.
  4. Made the ExceptionDescribe() calls conditional on the value of
     FontUtilities.debugFonts()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4572/files
  - new: https://git.openjdk.java.net/jdk/pull/4572/files/1622a169..d1bc82e8

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

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

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

From github.com+28651297+mkartashev at openjdk.java.net  Wed Jun 30 10:42:48 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Wed, 30 Jun 2021 10:42:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v2]
In-Reply-To: <QRHoUfQjNsw564I45z6SgcYSBw7MzZ9g644W8G74OWY=.62b31f52-9918-4d57-a9ae-5ec60567270f@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
 <QRHoUfQjNsw564I45z6SgcYSBw7MzZ9g644W8G74OWY=.62b31f52-9918-4d57-a9ae-5ec60567270f@github.com>
Message-ID: <pPtDSxlX3RUFfi6FK6kU9MO2lQg2U5LCdCU4VKjFiHI=.cb409465-b32b-4f59-a117-d3c40f033e3c@github.com>

On Wed, 30 Jun 2021 00:08:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed PR comments
>>   
>>   1. Allowed test to run on any platform.
>>   2. Trimmed comments to fit in with 80 columns.
>>   3. Removed unnecessayr comments.
>>   4. Made the ExceptionDescribe() calls conditional on the value of
>>      FontUtilities.debugFonts()
>
> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 53:
> 
>> 51:         (*(env))->ExceptionDescribe(env);\
>> 52:         (*(env))->ExceptionClear(env);   \
>> 53:     }
> 
> https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#exceptiondescribe
> 
> "The pending exception is cleared as a side-effect of calling this function"
> 
> So you certainly don't need both of these and I would prefer that Describe only be used if really debugging where we think there's a REAL chance of an exception rather than just to keep JNI happy.
> 
> And the upcall that is likely (readBlock) itself will log any IOException (and catch it) in the event of an I/O error so I really think this is unlikely to be useful here.

Yes, makes sense. I made `CHECK_EXCEPTION()` call either `Clear...` or `Describe...` based on the value of `debugFonts`. 
Please, take a look.

> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 198:
> 
>> 196:                                           sunFontIDs.ttReadBlockMID,
>> 197:                                           bBuffer, offset, numBytes);
>> 198:             // This is a callback, we are not returning immediately to Java and better report exceptions now
> 
> I think the comment is un-needed .. since the only reason to call CHECK_EXCEPTION() is because of this.
> Same for the other case.

OK, comments removed.

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

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

From github.com+28651297+mkartashev at openjdk.java.net  Wed Jun 30 10:42:52 2021
From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Wed, 30 Jun 2021 10:42:52 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8269223: -Xcheck:jni WARNINGs working
 with fonts on Linux [v2]
In-Reply-To: <NFFyA8m_x4iByCkTACJgZM03HzFiiuS6wsMhN_vOhrc=.ab61fb15-6a11-4dcd-8b62-c15f96d9f87b@github.com>
References: <9qME86kmJADg8GimR2jWTt831LWYfE3J19jrxKtrNS0=.1a62b00d-fbba-4cb3-aa28-450ab935d239@github.com>
 <NFFyA8m_x4iByCkTACJgZM03HzFiiuS6wsMhN_vOhrc=.ab61fb15-6a11-4dcd-8b62-c15f96d9f87b@github.com>
Message-ID: <lx0KD6GQ8tkpHDM055M1UUKtTDRwNbYYL1DJ5vWrD_g=.dcaa6acd-f795-46cd-81d8-b9f1ca87beab@github.com>

On Tue, 29 Jun 2021 23:19:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed PR comments
>>   
>>   1. Allowed test to run on any platform.
>>   2. Trimmed comments to fit in with 80 columns.
>>   3. Removed unnecessayr comments.
>>   4. Made the ExceptionDescribe() calls conditional on the value of
>>      FontUtilities.debugFonts()
>
> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 146:
> 
>> 144:     freeNativeResources(env, scalerInfo);
>> 145:     (*env)->CallVoidMethod(env, scaler, invalidateScalerMID);
>> 146:     // NB: Exceptions must not be cleared (and therefore no JNI calls performed) after calling this method
> 
> Please split long lines to 80 chars per line

Done.

> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 199:
> 
>> 197:                                           bBuffer, offset, numBytes);
>> 198:             // This is a callback, we are not returning immediately to Java and better report exceptions now
>> 199:             CHECK_EXCEPTION(env);
> 
> Probably we should report it only if "debugFonts" was set?

Done.

> test/jdk/java/awt/font/JNICheck/FreeTypeScalerJNICheck.java line 28:
> 
>> 26:  * @bug 8269223
>> 27:  * @summary Verifies that -Xcheck:jni issues no warnings from freetypeScaler.c
>> 28:  * @requires os.family == "linux"
> 
> Can we run this test on all platforms? Since this bug was not found, means we did not cover this code by the tests, and it will be useful to test it even if the code path will be different on other platforms.

Sure; dropped the `@requires` clause.

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

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

From aghaisas at openjdk.java.net  Wed Jun 30 11:42:04 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 30 Jun 2021 11:42:04 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
In-Reply-To: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
Message-ID: <YzwMOLjkj_frjOs2dPJeq8BWprEYD_1QsXD5WUGDi3A=.777af10d-193a-47cc-bc61-a3bf53347623@github.com>

On Tue, 29 Jun 2021 17:34:00 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
> In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().
> 
> Sanity and performance analysis is green. More details in JBS.

I tested this patch with applications such as SwingSet2 and NetBeans IDE with graphics card switching. Also, tested multi-monitor scenarios. No regression observed.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 88:

> 86: 
> 87:     if (self.nextDrawableCount != 0) {
> 88:         [self stopDisplayLink];

Please check invoking stopDisplayLink at this place.  If a Drawable is not available, we should return from here but recheck after 16ms. A drawable might be made available on subsequent attempts.

Stopping DisplayLink at other invalid cases makes sense.

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun 30 11:49:51 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 30 Jun 2021 11:49:51 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8268764: Use Long.hashCode() instead of
 int-cast where applicable [v2]
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

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

 - Merge branch 'master' into 8268764
 - 8268764: Use Long.hashCode() instead of int-cast where applicable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/27233ae1..12a1d3ac

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

  Stats: 44011 lines in 878 files changed: 23038 ins; 17963 del; 3010 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491

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

From kevinw at openjdk.java.net  Wed Jun 30 13:23:14 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 30 Jun 2021 13:23:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8268764: Use Long.hashCode() instead of
 int-cast where applicable [v2]
In-Reply-To: <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
Message-ID: <kQskR6msy1oj6QYFJZruPlVBkbchJQb7R-quaPk0r74=.4075ca4a-5724-4b7d-866e-e8895a9a721d@github.com>

On Wed, 30 Jun 2021 11:49:51 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8268764
>  - 8268764: Use Long.hashCode() instead of int-cast where applicable

The changes look good to me, we have done the same thing elsewhere.  This changes things in different functional areas, which is maybe unusual, but seems fine for a small change as long as nobody objects.

Some of the files also need a (C) year update.

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

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

From jdv at openjdk.java.net  Wed Jun 30 14:26:06 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 30 Jun 2021 14:26:06 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog
In-Reply-To: <YzwMOLjkj_frjOs2dPJeq8BWprEYD_1QsXD5WUGDi3A=.777af10d-193a-47cc-bc61-a3bf53347623@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <YzwMOLjkj_frjOs2dPJeq8BWprEYD_1QsXD5WUGDi3A=.777af10d-193a-47cc-bc61-a3bf53347623@github.com>
Message-ID: <pda_bFMo4hzXDFE8qA5aAHZkhlk6C5CztYsLAKRRvzw=.388fd0ea-2bb5-4622-9a89-6a121a64948a@github.com>

On Wed, 30 Jun 2021 11:36:18 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
>> In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().
>> 
>> Sanity and performance analysis is green. More details in JBS.
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 88:
> 
>> 86: 
>> 87:     if (self.nextDrawableCount != 0) {
>> 88:         [self stopDisplayLink];
> 
> Please check invoking stopDisplayLink at this place.  If a Drawable is not available, we should return from here but recheck after 16ms. A drawable might be made available on subsequent attempts.
> 
> Stopping DisplayLink at other invalid cases makes sense.

@aghaisas Thanks for the review. Redraw of static content is driven by setNeedsDisplay, because we stop CVDisplayLink once final blit is done. Also with preliminary testing i see that we are not hitting this condition at all after CVDisplayLink is enabled. We still have a verification task under https://bugs.openjdk.java.net/browse/JDK-8258583 . Stopping or not stopping CVDisplayLink at this place is not causing any change. I will go ahead and remove stopDisplayLink at this place, in future if we hit this code because of some boundary condition we can enable it and verify.

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From jdv at openjdk.java.net  Wed Jun 30 14:37:31 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 30 Jun 2021 14:37:31 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog [v2]
In-Reply-To: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
Message-ID: <-FZZ43SrkU-jrTHs8r2-nsFcNGqtIPMuYlSjO0SaeM4=.cca9ac80-7cd8-4dbc-8648-1b8dd1e865ca@github.com>

> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
> In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().
> 
> Sanity and performance analysis is green. More details in JBS.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Remove stopDisplayLink call when nextDrawableCount is not zero

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/175/files
  - new: https://git.openjdk.java.net/jdk17/pull/175/files/5b5914ab..cca4c900

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

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From serb at openjdk.java.net  Wed Jun 30 16:00:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Jun 2021 16:00:09 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog [v2]
In-Reply-To: <-FZZ43SrkU-jrTHs8r2-nsFcNGqtIPMuYlSjO0SaeM4=.cca9ac80-7cd8-4dbc-8648-1b8dd1e865ca@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <-FZZ43SrkU-jrTHs8r2-nsFcNGqtIPMuYlSjO0SaeM4=.cca9ac80-7cd8-4dbc-8648-1b8dd1e865ca@github.com>
Message-ID: <w3oGsx5_DAKIcfM6a7G4Dh4a3sQbrcji0Xd3egYIadw=.9bb55b89-1eee-492d-93a5-b45a756df0be@github.com>

On Wed, 30 Jun 2021 14:37:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Final blit operation in MTLLayer.blitTexture() is driven by CVDisplayLink in Metal.
>> In this test case we are hitting an invalid condition because of which we exit from MTLLayer.blitTexture(), but we are not stopping the CVDisplayLink. This is causing the CVDisplayLink callback to run in loop. Fix is to stop CVDisplayLink when we return without completing final blit operation in MTLLayer.blitTexture().
>> 
>> Sanity and performance analysis is green. More details in JBS.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stopDisplayLink call when nextDrawableCount is not zero

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/175

From serb at openjdk.java.net  Wed Jun 30 16:00:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Jun 2021 16:00:10 GMT
Subject: [OpenJDK 2D-Dev] [jdk17] RFR: 8267602: [macos] [lanai]
 java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print
 dialog [v2]
In-Reply-To: <mfuoOWjJSGCs4Ev2gZKuCRStjbjTJPz8y8ikfLz4KCM=.0d239f63-0aba-4d62-ad38-56b0db1c2849@github.com>
References: <igtGmLC3ndGDpnZ1qniB9T7XjTBQpmymeNIOw9PaPE4=.78711824-fead-4586-97bb-bd4c3c1fe781@github.com>
 <wF9gDRlgIpJjivO3ioHEmS3TRGzHI6jCYx5ATbiAN30=.71b594b7-f06d-407c-976f-248996474d82@github.com>
 <_6cyIO31CYIYiDKnfk92G9Ktww461LZi-NJ2RSxil84=.2122489c-5d07-48ce-bf95-ecb8224a448b@github.com>
 <YYWQOUp1bI3sCqvehkchKzjFaE0OkgsVsb3crrcoyRM=.e1f51fd6-7e29-470b-bb87-11c632a0b7da@github.com>
 <mfuoOWjJSGCs4Ev2gZKuCRStjbjTJPz8y8ikfLz4KCM=.0d239f63-0aba-4d62-ad38-56b0db1c2849@github.com>
Message-ID: <EI4r_7DL1ZE9uP4L2jMSQGWnqO0Al5vig1DOUpGqjVI=.3c8f1681-ec65-476e-b455-0917493414e4@github.com>

On Wed, 30 Jun 2021 08:09:28 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> No, I meant if we dispose the frame/exist from the app/etc before "Java_sun_java2d_metal_MTLLayer_blitTexture" method is executed but after we call "startDisplayLink", when we will call the stopDisplayLink in this case?
>
> @mrserb Please let me know if i can resolve this conversation.

ok, looks fine

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

PR: https://git.openjdk.java.net/jdk17/pull/175