Quick fix for openjdk20

[Alexey Ushakov]

> 
> 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). 

Best Regards,
Alexey

> On Dec 7, 2022, at 7:22 PM, Philip Race <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/515f18af/attachment.htm>