Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]

[Gerard Ziemski]

On Thu, 11 Feb 2021 20:55:47 GMT, Gerard Ziemski <gziem...@openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with two additional 
>> commits since the last revision:
>> 
>>  - Lanai PR#181 - 8261143 - aghaisas
>>  - Lanai PR#180 - 8261546 - jdv
>
> Changes requested by gziemski (Committer).

I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed a 
startup time regression with the Metal rendering pipeline, so I dug a bit and 
here is what I found using Xcode startup profiler:

Here is the OpenGL pipeline:
<img width="1904" alt="OpenGL" 
src="https://user-images.githubusercontent.com/63425797/107981859-8efb4780-6f88-11eb-849a-385c29f3ff6f.png";>


Here is the Metal pipeline:
<img width="1904" alt="Metal" 
src="https://user-images.githubusercontent.com/63425797/107981882-9ae70980-6f88-11eb-9b73-d1bd19dfa07f.png";>

If I read the results correctly, there is a weird 330ms time gap in the case of 
the Metal pipeline where nothing is done and it looks like the culprit is 
`Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable`

The OpenGL pipeline gets blocked only for 83ms in 
`Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo`

I would advice that we take a closer look at why 
'Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable' takes so 
long, and optimize it, or cache the results, so the next VM instance can skip 
it if needed (assuming the call doesn't end up initializing the native Metal or 
something like that), still worth taking a look.

I would also recommend that you adopt Xcode and its Instruments profiler tools 
for future work. Please let me know if you need help in this area.

I only scratched the surface here and I think that there is plenty of profiling 
that can be done to investigate the startup time regression further.

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

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