[OpenJDK 2D-Dev] Integrated: 8264428: Cleanup usages of StringBuffer in java.desktop
On Mon, 29 Mar 2021 20:50:14 GMT, Andrey Turbanov wrote: > There are few possible cleanups in java.desktop related to legacy > StringBuffer usages: > 1. In few places StringBuffer can be replaced with plain String concatenation. > 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better > performance as it is not thread-safe. > 3. There are few places where result of string concatenation is passed to > StringBuffer.append method. Using separate `.append` calls is more clear. > 4. In few places primitives are unnecessary converted to String before > `.append` call. They can be replaced with specialized methods (like > `.append(int)` calls. This pull request has now been integrated. Changeset: 8a235807 Author:Andrey Turbanov Committer: Alexander Zvegintsev URL: https://git.openjdk.java.net/jdk/commit/8a235807 Stats: 48 lines in 11 files changed: 3 ins; 8 del; 37 mod 8264428: Cleanup usages of StringBuffer in java.desktop Reviewed-by: azvegint, aivanov - PR: https://git.openjdk.java.net/jdk/pull/3251
Re: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo
On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste > error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 Marked as reviewed by kizune (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3397
Re: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo
On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste > error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 Marked as reviewed by azvegint (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3397
Re: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1
On Wed, 7 Apr 2021 19:54:03 GMT, Sergey Bylokhov wrote: > I wonder why we have two similar but different constants: > #define MaxTextureSize 16384 > #define MTL_GPU_FAMILY_MAC_TXT_SIZE 16384 I can remove MaxTextureSize and replace its usages. Should I file a new bug or put changes in this PR? - PR: https://git.openjdk.java.net/jdk/pull/3369
Re: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4]
On Thu, 8 Apr 2021 14:43:50 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy >> StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String >> concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better >> performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to >> StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before >> `.append` call. They can be replaced with specialized methods (like >> `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8264484: Replace uses of StringBuffer with StringBuilder in > jdk.hotspot.agent > > place each 'append' call on its own line Marked as reviewed by azvegint (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3251
Re: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai]
On Wed, 7 Apr 2021 20:29:12 GMT, Alexey Ushakov wrote: >>> @avu Test passes without fix also. >> @jayathirthrao Could you provide the details about your configuration along >> with parameters passed to jtreg ? > >> @avu I am running test in 13 inch Macbook Early 2015 with integrated Intel >> Iris Graphics 6100. >> jtreg command i am using "jtreg -jdk: -Dsun.java2d.metal=true >> " > @jayathirthrao I'm not sure that -Dsun.java2d.metal had been passed to the > test JVM. I rechecked with slightly different command line and the test fails > without the fix > jtreg -ignore:quiet -v -a -xml -vmoptions:"-Dsun.java2d.metal=True " > -testjdk:path_to_jdk path_to_test I've created a simpler solution within another pull request. Please, have a look https://git.openjdk.java.net/jdk/pull/3390 - PR: https://git.openjdk.java.net/jdk/pull/3308
Re: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4]
On Thu, 8 Apr 2021 14:43:50 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy >> StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String >> concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better >> performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to >> StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before >> `.append` call. They can be replaced with specialized methods (like >> `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8264484: Replace uses of StringBuffer with StringBuilder in > jdk.hotspot.agent > > place each 'append' call on its own line Marked as reviewed by aivanov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3251
Re: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4]
> There are few possible cleanups in java.desktop related to legacy > StringBuffer usages: > 1. In few places StringBuffer can be replaced with plain String concatenation. > 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better > performance as it is not thread-safe. > 3. There are few places where result of string concatenation is passed to > StringBuffer.append method. Using separate `.append` calls is more clear. > 4. In few places primitives are unnecessary converted to String before > `.append` call. They can be replaced with specialized methods (like > `.append(int)` calls. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent place each 'append' call on its own line - Changes: - all: https://git.openjdk.java.net/jdk/pull/3251/files - new: https://git.openjdk.java.net/jdk/pull/3251/files/963dc56e..d083f953 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3251=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3251=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3251.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3251/head:pull/3251 PR: https://git.openjdk.java.net/jdk/pull/3251
Re: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3]
On Wed, 7 Apr 2021 15:21:40 GMT, Alexey Ivanov wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop
>>
>> fix copyright year
>
> src/java.desktop/unix/classes/sun/awt/X11/XCreateWindowParams.java line 88:
>
>> 86: while (eIter.hasNext()) {
>> 87: Map.Entry entry = eIter.next();
>> 88: buf.append(entry.getKey()).append(":
>> ").append(entry.getValue()).append("\n");
>
> Would it be clearer if each append was on its own line?
> Suggestion:
>
> buf.append(entry.getKey())
>.append(": ")
>.append(entry.getValue())
>.append("\n");
done
-
PR: https://git.openjdk.java.net/jdk/pull/3251
Re: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo
On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste > error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 Marked as reviewed by jdv (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3397
Re: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo
On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste > error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 Marked as reviewed by aivanov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3397
[OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo
Noticed this when backporting JDK-8242557: there is a trivial copy-paste error in exception message. See: https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 - Commit messages: - 8264923: PNGImageWriter.write_zTXt throws Exception with a typo Changes: https://git.openjdk.java.net/jdk/pull/3397/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3397=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264923 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3397.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3397/head:pull/3397 PR: https://git.openjdk.java.net/jdk/pull/3397
Re: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v3]
> Refer JBS for 3 issues that this PR addresses. > In addition, I have corrected an erroneous free() call in the same method I > was cleaning up. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: log message correction - Changes: - all: https://git.openjdk.java.net/jdk/pull/3357/files - new: https://git.openjdk.java.net/jdk/pull/3357/files/36ed087b..45e7aec0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3357=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3357=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3357/head:pull/3357 PR: https://git.openjdk.java.net/jdk/pull/3357
Re: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v2]
> Refer JBS for 3 issues that this PR addresses. > In addition, I have corrected an erroneous free() call in the same method I > was cleaning up. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Review fixes - Changes: - all: https://git.openjdk.java.net/jdk/pull/3357/files - new: https://git.openjdk.java.net/jdk/pull/3357/files/ade2381d..36ed087b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3357=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3357=00-01 Stats: 128 lines in 1 file changed: 20 ins; 81 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/3357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3357/head:pull/3357 PR: https://git.openjdk.java.net/jdk/pull/3357
Re: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v2]
On Wed, 7 Apr 2021 02:50:03 GMT, Sergey Bylokhov wrote:
>> Ajit Ghaisas has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review fixes
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line
> 149:
>
>> 147: try {
>> 148: // getMTLConfigInfo() creates new MTLContext, so we should
>> first
>> 149: // invalidate the current Java-level context and flush the
>> queue...
>
> The old discussion was related not only to the comment but to the
> invalidateCurrentContext, do we need to do it?
This is the only place where we use MTLContext.invalidateCurrentContext() -
which when processed in MTLRenderQueue - clears some native stuff and nulls out
both mtlc and dstOps pointers maintained in MTLRenderQueue.m. I think, this
will be important once we get rid of SET_SCRATCH_SURFACE under JDK-8263309.
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m
> line 152:
>
>> 150: NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
>> 151:
>> 152:
>
> Please also check how this function is called, looks like previously it was
> called as a selector+an array as a parameter, and then reworked as a
> performOnMainThreadWaiting+block, but it still use an array as a parameter. I
> think it is similar to JDK-8238075.
Excellent point! Thanks for the pointer to the bug.
A lot of code in this file can be cleaned up. I will update the PR soon.
-
PR: https://git.openjdk.java.net/jdk/pull/3357
