RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType layout [v4]

[Jorn Vernee]

On Thu, 16 Nov 2023 01:54:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > > So we have somewhere around a fixed 125ms startup cost for the FFM case - as measured on my Mac,
> > > > but only 35-40ms of that is attributable to the specific needs of layout.
> > > 
> > > 
> > > That looks unfortunate. I guess if we will start to use ffm in other places we can easily spend of 1 second budget on startup=(
> > 
> > 
> > Yes, this case is sufficiently uncommon, that it is OK, and is a decent way to help us track improvements to FFM. But it would be another matter to have to do it for however many of our core software loops and AWT window manager interaction calls we need to get running for a minimal app.
> > > > layoutCnt=16000 total=193ms <<< app fully displayed
> > > > vs
> > > > layoutCnt=16000 total=453ms <<< app fully displayed
> > > 
> > > 
> > > It looks strange that 16000 calls are not enough to warmup, and the difference is so large.
> > 
> > 
> > I am not a C2 expert, (not even an amateur), I just assume that it takes a lot of calls to be fully optimized.
> 
> @JornVernee this looks suspicious and seems unrelated to the cold startup issues we discussed before.

I suspect the benchmark might be measuring the java.lang.foreign code needing to be loaded as part of the benchmark. While for JNI, the initialization of all the JNI machinery is included in the startup of the application. Was the running time of the entire application/process measured? Or only from the start of the `main` method?

Secondly, we have not spent a lot of time optimizing the startup performance of FFM yet. There are things we could do such as pre-generating classes during jlink-time, similar to what we do for java.lang.invoke/lambda implementation classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1815189946