<AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]

Gerard Ziemski gziemski at openjdk.java.net
Mon Feb 15 20:23:41 UTC 2021

On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski <gziemski at 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

More information about the awt-dev mailing list