Quick fix for openjdk20

[Alexey Ushakov]

Hi Ajit,

According to the tests you’ve mentioned it’s not a big difference. Looks like we’ve faced with completely different scenario. I’ll try to figure out the main reason of the failure.

Best Regards,
Alexey 

> On Dec 8, 2022, at 12:38 PM, Ajit Ghaisas <ajit.ghaisas at oracle.com> wrote:
> 
> 
> 
>> On 08-Dec-2022, at 1:50 PM, Alexey Ushakov <alexey.ushakov at jetbrains.com <mailto:alexey.ushakov at jetbrains.com>> wrote:
>> 
>>> 
>>> FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
>>> time for these things to be discovered.
>> Could you provide some more details concerning the regression? We also faced with a regression in metal rendering (https://youtrack.jetbrains.com/issue/JBR-4849 ). It was caused by https://bugs.openjdk.org/browse/JDK-8288948 (that we back ported into OpenJDK17 based runtime). 
> 
> The details can be found at - 
> https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14504772 <https://bugs.openjdk.org/browse/JDK-8288948?focusedCommentId=14504772&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14504772>
> 
> Look at the last 3 lines of that comment & attached test results to  https://bugs.openjdk.org/browse/JDK-8288948.
> In the screenshots for RenderPerf and SwingMark results - the rightmost column header should read “Integrated graphics card."
> 
>> 
>> Best Regards,
>> Alexey
>> 
>>> On Dec 7, 2022, at 7:22 PM, Philip Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>> 
>>> This is clearly too late for JDK 20 and JDK 21 will be just 6 months later so it is a better time for that.
>>> FWIW we have just had at a report of a performance drop in JDK 20 from a b07 change to show how it takes
>>> time for these things to be discovered.
>>> Also I had a bug / rfe for this a while back : https://bugs.openjdk.org/browse/JDK-8233037
>>> I closed it as WNF because I wasn't able to see a performance boost.
>>> 
>>> So the right way to do this is  to provide some solid evidence of what gets faster and what gets
>>> slower with a range of different values (not just the JBR one) and re-open that bug and resolve early in 21.
>>> 
>>> -phil.
>>> 
>>> 
>>> On 12/7/22 7:36 AM, Alexey Ushakov wrote:
>>>> Yes, I confirm that we’ve been using such enlarged buffer for a long time in production. It helped us with scrolling performance on 4K monitors. The suggested property could help to adjust the buffer for the needs of particular application.
>>>> 
>>>> Best Regards,
>>>> Alexey
>>>> 
>>>>> On 7 Dec 2022, at 11:37, Laurent Bourgès <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> For years, JetBrains Runtime uses a larger render queue buffer size (32kb to 6,400,000 bytes) in production, as it boosted many accelerated pipelines: d3d, ogl, metal :
>>>>> ~ 10 to 20% on large fills...
>>>>> 
>>>>> JBR RenderQueue:
>>>>> https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>>>>> 
>>>>> JDK RenderQueue:
>>>>> https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75
>>>>> 
>>>>> I want to propose such quick fix in openjdk20 today, as a 1-line fix.
>>>>> 
>>>>> 
>>>>> /** The size of the underlying buffer, in bytes. */
>>>>> private static final int BUFFER_SIZE = 6400000;
>>>>> 
>>>>> To ensure a smooth transition, I prefer introducing a new sun.java2d.render.queue system property to increase the default (32kb) buffer capacity:
>>>>> 
>>>>> See in marlin:
>>>>> https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java#L78
>>>>> 
>>>>> So here is my current proposal:
>>>>> [[[
>>>>> 
>>>>> /** The size of the underlying buffer, in bytes. */
>>>>> private static final int BUFFER_SIZE;
>>>>> 
>>>>> static {
>>>>> // Default 32K is too small for high-end GPU:
>>>>> BUFFER_SIZE = align(getInteger("sun.java2d.render.bufferSize", 32 * 1024, 32 * 1024, 16 * 1024 * 1024), 1024);
>>>>> 
>>>>> // System.out.println("RenderQueue: sun.java2d.render.bufferSize = " + BUFFER_SIZE);
>>>>> }
>>>>> 
>>>>>     // system property utilities
>>>>>     public static int getInteger(final String key, final int def,
>>>>>                                  final int min, final int max)
>>>>>     {
>>>>>         final String property = AccessController.doPrivileged(
>>>>>                                     new GetPropertyAction(key));
>>>>> 
>>>>>         int value = def;
>>>>>         if (property != null) {
>>>>>             try {
>>>>>                 value = Integer.decode(property);
>>>>>             } catch (NumberFormatException e) {
>>>>>                 System.out.println("Invalid integer value for " + key + " = " + property);
>>>>>             }
>>>>>         }
>>>>> 
>>>>>         // check for invalid values
>>>>>         if ((value < min) || (value > max)) {
>>>>>             System.out.println("Invalid value for " + key + " = " + value
>>>>>                     + "; expected value in range[" + min + ", " + max + "] !");
>>>>>             value = def;
>>>>>         }
>>>>>         return value;
>>>>>     }
>>>>> 
>>>>>     protected static int align(final int val, final int norm) {
>>>>>         final int ceil = (int)Math.ceil( ((float) val) / norm);
>>>>>         return ceil * norm;
>>>>>     }
>>>>> ]]]
>>>>> 
>>>>> Would you accept such late change for openjdk20 ?
>>>>> 
>>>>> Cheers,
>>>>> Laurent Bourgès 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221208/2992e13e/attachment.htm>