[External] : Re: Quick fix for openjdk20

[Ajit Ghaisas]

Hi Alexey,

   There could be other reasons as well, but - those recorded results were for x64 only at that time. Performance degradation is comparatively more when run on M1 systems.

Regards,
Ajit

On 09-Dec-2022, at 12:50 AM, Alexey Ushakov <alexey.ushakov at jetbrains.com<mailto:alexey.ushakov at jetbrains.com>> wrote:

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<mailto: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<https://urldefense.com/v3/__https://youtrack.jetbrains.com/issue/JBR-4849__;!!ACWV5N9M2RV99hQ!IGt32jobqI206Dm2bA6yJfDrvnugMoQygowL66VIPXfegeFCuprHsXLVNZUDG7C_y1gzas0MW8u8hEEMAjvAoIMxls-dzg$> ). 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<https://urldefense.com/v3/__https://github.com/JetBrains/JetBrainsRuntime/blob/02bc54f8644c6c6467aa952d0a8a104355acc273/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java*L75__;Iw!!ACWV5N9M2RV99hQ!IGt32jobqI206Dm2bA6yJfDrvnugMoQygowL66VIPXfegeFCuprHsXLVNZUDG7C_y1gzas0MW8u8hEEMAjvAoIOFwmNyEA$>

JDK RenderQueue:
https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java#L75<https://urldefense.com/v3/__https://github.com/bourgesl/jdk-official/blob/5e196b4b8e623107424e2fb54672790fd925fe73/src/java.desktop/share/classes/sun/java2d/pipe/RenderQueue.java*L75__;Iw!!ACWV5N9M2RV99hQ!IGt32jobqI206Dm2bA6yJfDrvnugMoQygowL66VIPXfegeFCuprHsXLVNZUDG7C_y1gzas0MW8u8hEEMAjvAoINZwGQdSw$>

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<https://urldefense.com/v3/__https://github.com/bourgesl/marlin-renderer/blob/323f1fb1c72704f5e86c8a13393e30df00888821/src/main/java/sun/java2d/pipe/RenderQueue.java*L78__;Iw!!ACWV5N9M2RV99hQ!IGt32jobqI206Dm2bA6yJfDrvnugMoQygowL66VIPXfegeFCuprHsXLVNZUDG7C_y1gzas0MW8u8hEEMAjvAoIN2g-fa0g$>

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/20221209/09759f49/attachment.htm>