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

[Gerard Ziemski]

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).
> 
> Hi Gerard, expecting a process and parsing its output is definitely not ideal 
> and that's why there's this open bug.
> One thing that is under consideration is to equate >= 10.14 with Metal is 
> available since as of 10.14 macOS won't install if a system does not support 
> metal. We have no compelling reason to support metal on earlier releases 
> anyway .. those are either already unsupported or barely supported and OGL 
> will always be available there.

I did not know that there already was a bug covering this issue.

Your idea seems reasonable.

More than just focusing on this immediate issue, however, I was hoping to raise 
the point of us starting adopting profiling tools to analyze our code (memory 
utilization, leaks, cpu/gpu profiling etc). A new feature that brings 10% 
benefit, but uses 50% more resources for example would probably not be a good 
investment. And to figure that we need to relay on some good tools and Xcode 
provides some.

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

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