Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]

[Ajit Ghaisas]

On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski <gziem...@openjdk.org> wrote:

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

Thanks @gerard-ziemski for taking a detailed look at this.
We do have an open bug to address this. Please refer 
[JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825).

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

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