On Mon, 24 Jun 2024 22:25:22 GMT, Phil Race <p...@openjdk.org> wrote:
>> Migrate font code from jdk.internal.misc.Unsafe to using FFM. >> This reduces the coupling between the java.desktop module and the internals >> of the java.base module. >> >> The code being changed here is not particularly performance sensitive, and >> it is not executed in the most common cases. >> The main impact performance-wise is a total of around 37ms in initialisation >> costs on my x64 macbook. >> A minimal program that just draws a string to an image - does not even put >> up a window - runs at around 690-700ms. >> There's variability in that number and the overall time for a JDK without >> the change is around (660-670ms) >> In the small test, this is the first and only use of FFM, so the one-off >> part cost should move elsewhere when FFM starts >> to be used earlier in the JDK itself. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8334495 > DId ffm team check from where that slow down come from? is it expected to > lose 5%? > > > In the small test, this is the first and only use of FFM, so the one-off > > part cost should move elsewhere when FFM starts > > to be used earlier in the JDK itself. > > So the changed code path will work as before (w/o slowdown) if the #15476 > will be touched by the test? and slow down will occur if > "sun.font.layout.ffm" will be set to false? Just would like to confirm that > we will not get "multiplication of slowdowns" for each ffm usage. Well there's going to be some fraction of it in order to create the VarHandles but the initialisation cost of the classes used by the FFM implementation is one time even if both are used, so it just depends who gets there first as to where it is seen, and if both are used, then only one will take that initialisation cost. However the layout code creates downcall and upcall stubs too, so it has a bigger one time cost than this code. In other words if hypothetically : - 30 ms one time init machinery cost for this cache code - 80 ms one time init machinery cost for the layout FFM code and this code is executed first, then layout would see a 50 ms cost, or if the layout code is executed first then I'd expect to see zero machinery init cost here. There's still *some* cost for each VarHandle etc. Executing code isn't free. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19777#issuecomment-2190048299
