8348830: LIBFONTMANAGER optimization is always HIGHEST #23332

MBaesken · 2025-01-28T13:32:56Z

In the makefile we reset LIBFONTMANAGER optimization, but is always set to HIGHEST so we can avoid the resetting.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8348830: LIBFONTMANAGER optimization is always HIGHEST (Bug - P4)

Reviewers

Erik Joelsson (@erikj79 - Reviewer)
Phil Race (@prrace - Reviewer)
Sergey Bylokhov (@mrserb - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23332/head:pull/23332
$ git checkout pull/23332

Update a local copy of the PR:
$ git checkout pull/23332
$ git pull https://git.openjdk.org/jdk.git pull/23332/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23332

View PR using the GUI difftool:
$ git pr show -t 23332

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23332.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-01-28T13:33:57Z

👋 Welcome back mbaesken! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-01-28T13:34:59Z

@MBaesken This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8348830: LIBFONTMANAGER optimization is always HIGHEST

Reviewed-by: erikj, prr, serb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 11 new commits pushed to the master branch:

98a93e1: 8348800: Many serviceability/sa tests failing after JDK-8348239
5e81fa6: 8348892: Properly fix compilation error for zip_util.c on Windows
3a564ed: 8347955: TimeZone methods to stream the available timezone IDs
1efae9a: 8348888: tier1 closed build failure on Windows after JDK-8348348
c018a60: 8344637: Fix Page8 of manual test java/awt/print/PrinterJob/PrintTextTest.java on Linux and Windows
c3c3888: 8336760: [JVMCI] -XX:+PrintCompilation should also print "hosted" JVMCI compilations
9f4d3de: 8347718: Unexpected NullPointerException in C2 compiled code due to ReduceAllocationMerges
a224f12: 8348205: Improve cutover time selection when building available currencies set
8103256: 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c
fb066ca: 8347272: [ubsan] JvmLauncher.cpp:262:52: runtime error: applying non-zero offset 40 to null pointer
... and 1 more: https://git.openjdk.org/jdk/compare/2bef5b4a877f4d3bc766558b8782b7b57dee79a8...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-01-28T13:35:42Z

@MBaesken The following labels will be automatically applied to this pull request:

build
client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-01-28T13:38:55Z

Webrevs

00: Full (fe3e66c8)

MBaesken · 2025-01-28T14:35:45Z

Hi Erik, thanks for the review !

I noticed this issue, while going through the make rules of our libs; any idea why so many are set to OPTIMIZATION level LOW ? Is this really still needed or just because of old compilers used many years ago?
For some libs the OPTIMIZATION level is not set (e.g. BUILD_LIBSYSLOOKUP) is this okay ? Guess some default is used in those cases?

Lib compilation current optimization level
BUILD_LIBJVM varies
BUILD_LIBNET LOW
BUILD_LIBNIO HIGH
BUILD_LIBOSXSECURITY LOW
BUILD_LIBJSIG LOW
BUILD_LIBSYSLOOKUP nothing set ??
BUILD_LIBFALLBACKLINKER nothing set ??
BUILD_LIBSIMD_SORT HIGH
BUILD_LIBVERIFY HIGH
BUILD_LIBJAVA HIGH
BUILD_LIBZIP LOW
BUILD_LIBJIMAGE LOW
BUILD_LIBJLI HIGH
BUILD_LIBJSOUND LOW
BUILD_LIBOSXAPP LOW
BUILD_LIBOSX LOW
BUILD_LIBAWT HIGHEST
BUILD_LIBAWT_HEADLESS LOW
BUILD_LIBAWT_XAWT LOW
BUILD_LIBAWT_LWAWT LOW
BUILD_LIBJAWT LOW
BUILD_LIBMLIB_IMAGE HIGHEST
BUILD_LIBLCMS HIGHEST
BUILD_LIBJAVAJPEG HIGHEST
BUILD_LIBSPLASHSCREEN LOW
BUILD_LIBFREETYPE HIGHEST
BUILD_LIBFONTMANAGER HIGHEST
BUILD_LIBOSXUI LOW
BUILD_LIBINSTRUMENT LOW
BUILD_LIBMANAGEMENT HIGH
BUILD_LIBPREFS HIGH
BUILD_LIBRMI LOW
BUILD_LIBJ2GSS LOW
BUILD_LIBSSPI_BRIDGE LOW
BUILD_LIBW2K_LSA_AUTH LOW
BUILD_LIBOSXKRB5 LOW
BUILD_LIBJ2PCSC LOW
BUILD_LIBJAVAACCESSBRIDGE LOW
BUILD_LIBWINDOWSACCESSBRIDGE LOW
BUILD_LIBATTACH LOW
BUILD_LIBJ2PKCS11 LOW
BUILD_LIBSUNMSCAPI LOW
BUILD_LIBSAPROC HIGH
BUILD_LIBJSVML nothing set ??
BUILD_LIBSLEEF HIGH
BUILD_LIBDT_SHMEM LOW
BUILD_LIBDT_SOCKET LOW
BUILD_LIBJDWP LOW
BUILD_LIBJPACKAGEAPPLAUNCHERAUX LOW
BUILD_LIBJPACKAGE LOW
BUILD_LIBWIXHELPER LOW
BUILD_LIBMANAGEMENT_AGENT LOW
BUILD_LIBMANAGEMENT_EXT HIGH
BUILD_LIBEXTNET LOW
BUILD_LIBSCTP LOW
BUILD_LIBJAAS LOW

prrace · 2025-01-28T19:43:32Z

Not all libraries do especially performance critical things.
For the client ones, fontmanager (does opentype layout), freetype (font rasterisation), awt (many of the core rendering loops), lcms (color processing), jpeg (image decoding), mlib_image (image processing) are ones where HIGHEST is set and should be important. For the rest, it is is probably not critical, so LOW should not be a problem.

MBaesken · 2025-01-29T08:21:30Z

Thanks for the reviews !

Not all libraries do especially performance critical things.

Agree, it was not my suggestion to set everywhere HIGH/HIGHEST . The question I had is - are there libraries where we set LOW because higher/other opt-levels would break the library (compilation and also runtime - wise) ?
For most of the libs probably other opt levels would work too, but it is hard to say in general.
Other question - for hotspot / libjvm we have the option to influence the opt - level we want to use in the build, e.g. by setting jvm feature opt-size and als link-time-optimization .
As far as I know we do not have this yet for JDK native libs. I would like to have it at least for libs where it is possible and does not break anything (probably some opt-in parameter of the make rule of the lib ).

MBaesken · 2025-01-29T08:21:47Z

/integrate

openjdk · 2025-01-29T08:22:45Z

Going to push as commit 168a471.
Since your change was applied there have been 12 commits pushed to the master branch:

55c3e78: 8348631: Crash in PredictedCallGenerator::generate after JDK-8347006
98a93e1: 8348800: Many serviceability/sa tests failing after JDK-8348239
5e81fa6: 8348892: Properly fix compilation error for zip_util.c on Windows
3a564ed: 8347955: TimeZone methods to stream the available timezone IDs
1efae9a: 8348888: tier1 closed build failure on Windows after JDK-8348348
c018a60: 8344637: Fix Page8 of manual test java/awt/print/PrinterJob/PrintTextTest.java on Linux and Windows
c3c3888: 8336760: [JVMCI] -XX:+PrintCompilation should also print "hosted" JVMCI compilations
9f4d3de: 8347718: Unexpected NullPointerException in C2 compiled code due to ReduceAllocationMerges
a224f12: 8348205: Improve cutover time selection when building available currencies set
8103256: 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c
... and 2 more: https://git.openjdk.org/jdk/compare/2bef5b4a877f4d3bc766558b8782b7b57dee79a8...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-01-29T08:22:54Z

@MBaesken Pushed as commit 168a471.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

MBaesken · 2025-01-29T13:43:09Z

BUILD_LIBAWT_XAWT LOW

Regarding BUILD_LIBAWT_XAWT I wonder why LOW is set; there is some java2d / OGL coding in the lib and there the performance is probably important?

java.desktop/libawt_xawt/AccelGlyphCache.o
java.desktop/libawt_xawt/CUPSfuncs.o
java.desktop/libawt_xawt/GLXGraphicsConfig.o
java.desktop/libawt_xawt/GLXSurfaceData.o
java.desktop/libawt_xawt/OGLBlitLoops.o
java.desktop/libawt_xawt/OGLBufImgOps.o
java.desktop/libawt_xawt/OGLContext.o
java.desktop/libawt_xawt/OGLFuncs.o
java.desktop/libawt_xawt/OGLMaskBlit.o
java.desktop/libawt_xawt/OGLMaskFill.o
java.desktop/libawt_xawt/OGLPaints.o
java.desktop/libawt_xawt/OGLRenderQueue.o
java.desktop/libawt_xawt/OGLRenderer.o
java.desktop/libawt_xawt/OGLSurfaceData.o
java.desktop/libawt_xawt/OGLTextRenderer.o
java.desktop/libawt_xawt/OGLVertexCache.o
java.desktop/libawt_xawt/X11Color.o
java.desktop/libawt_xawt/X11FontScaler_md.o
java.desktop/libawt_xawt/X11PMBlitLoops.o
java.desktop/libawt_xawt/X11Renderer.o
java.desktop/libawt_xawt/X11SurfaceData.o
java.desktop/libawt_xawt/X11TextRenderer_md.o
java.desktop/libawt_xawt/XRBackendNative.o
java.desktop/libawt_xawt/XRSurfaceData.o
java.desktop/libawt_xawt/XToolkit.o
java.desktop/libawt_xawt/XWindow.o
java.desktop/libawt_xawt/XlibWrapper.o
java.desktop/libawt_xawt/awt_AWTEvent.o
java.desktop/libawt_xawt/awt_Desktop.o
java.desktop/libawt_xawt/awt_DrawingSurface.o
java.desktop/libawt_xawt/awt_Event.o
java.desktop/libawt_xawt/awt_Font.o
java.desktop/libawt_xawt/awt_GraphicsEnv.o
java.desktop/libawt_xawt/awt_InputMethod.o
java.desktop/libawt_xawt/awt_Insets.o
java.desktop/libawt_xawt/awt_Robot.o
java.desktop/libawt_xawt/awt_Taskbar.o
java.desktop/libawt_xawt/awt_UNIXToolkit.o
java.desktop/libawt_xawt/awt_util.o
java.desktop/libawt_xawt/fontpath.o
java.desktop/libawt_xawt/gnome_interface.o
java.desktop/libawt_xawt/gtk3_interface.o
java.desktop/libawt_xawt/gtk_interface.o
java.desktop/libawt_xawt/list.o
java.desktop/libawt_xawt/multiVis.o
java.desktop/libawt_xawt/rect.o
java.desktop/libawt_xawt/screencast_pipewire.o
java.desktop/libawt_xawt/screencast_portal.o
java.desktop/libawt_xawt/sun_awt_X11_GtkFileDialogPeer.o
java.desktop/libawt_xawt/swing_GTKEngine.o
java.desktop/libawt_xawt/swing_GTKStyle.o
java.desktop/libawt_xawt/systemScale.o

magicus · 2025-01-29T23:25:51Z

The problem with changing optimization levels is that folks are generally conservative and worried that things might break, that are hard to detect. I'm not convinced that the risk of changing optimization level is any larger than upgrading the compiler though, so maybe that is not a very good argument.

As has been pointed out e.g. by Phil, not all libraries are performance critical. With that said, maybe such libraries should be optimized for size instead? (In many cases that also brings along a speed performance, even if it by no means guaranteed.)

Changing optimization levels should not only be measured on the execution speed of the final product, but also on how much it affects the build time.

If you feel up for it, I suggest that you go through all libraries you want to update, change the optimization levels to what you think is reasonable, measure any relevant performance benchmarks before and after, and also the the build time. (hint: Use e.g. make java.desktop-libs-only JOBS=1 LOG=info to get a build speed number that you can compare across compiler flag changes) Run all relevant tests that stress that native component.

Then you can post a PR and suggest that we change the optimization level.

I'm all in favor of this, I'm not just in favor of having to do all the work needed myself. :-)

MBaesken · 2025-01-30T16:20:12Z

As has been pointed out e.g. by Phil, not all libraries are performance critical. With that said, maybe such libraries should be
optimized for size instead? (In many cases that also brings along a speed performance, even if it by no means guaranteed.)

Hi Magnus, that sounds like a good idea, especially for libraries that are a bit larger (if they are below 100K it does probably not make a big difference).
Some candidates that have optimization LOW and are larger than 150K ; results are from opt builds
For Linux x86_64 I added the normal/low size and the one when changing from LOW to SIZE optimization

	linuxx86_64 (LOW -> SIZE)	macosaarch64	windows-x86_64
BUILD_LIBAWT_XAWT	540K -> 480K
BUILD_LIBAWT_LWAWT		1.2M
BUILD_LIBZIP		164K
BUILD_LIBSPLASHSCREEN	364K -> 304K	468K	204K
BUILD_LIBJDWP	330K -> 268K	312K	228K
BUILD_LIBJAVAACCESSBRIDGE			280K

BUILD_LIBJSVML is also rather large (~ 850K) but has no opt-level set for the lib make rule; not sure what that means, almost all other libs set a specific optimization level .

( Besides changing a couple of default opt-levels for some libs, I also would like to have better configure functionality to set it myself like we have for libjvm with the 'jvm-features' . )

magicus · 2025-01-30T19:47:55Z

I don't think there is much point in being able to vary the opt level; it is more about spending the time to find the most appropriate opt level, and once you've done that, you can update the makefile directly.

MBaesken · 2025-01-31T12:16:54Z

I don't think there is much point in being able to vary the opt level; it is more about spending the time to find the most appropriate opt level, and once you've done that, you can update the makefile directly.

You want to optimize for binary size in some scenarios but not in all.
And when looking at binary size (maybe also performance in some special cases) lto is promising for some jdk libs but at least for now you don't want to enable it as a default.

Still, for some simple cases like e.g. BUILD_LIBSPLASHSCREEN changing the opt level from LOW to SIZE is probably the best thing to do after some more testing.

TheShermanTanker · 2025-01-31T13:59:45Z

I don't think there is much point in being able to vary the opt level; it is more about spending the time to find the most appropriate opt level, and once you've done that, you can update the makefile directly.

You want to optimize for binary size in some scenarios but not in all. And when looking at binary size (maybe also performance in some special cases) lto is promising for some jdk libs but at least for now you don't want to enable it as a default.

Still, for some simple cases like e.g. BUILD_LIBSPLASHSCREEN changing the opt level from LOW to SIZE is probably the best thing to do after some more testing.

I think LTO ability for native JDK code could be worthwhile as a flag, but having a JVM opt-size equivalent for the JDK native code is not as beneficial, given not many are really interested in the individual optimization levels of each module. In any case LibCommon.gmk and LauncherCommon.gmk is where I put these optimization overrides in my fork

MBaesken · 2025-02-03T12:20:05Z

Still, for some simple cases like e.g. BUILD_LIBSPLASHSCREEN changing the opt level from LOW to SIZE is probably the best
thing to do after some more testing.

The size optimization worked pretty well on most platforms , have to look still more into the compilation times of the this lib for a complete picture. No jtreg/jck failures seen.
These are the sizes when comparing LOW to SIZE optimization
Linux ppc64le 500K -> 376K
Linux x86_64 364k -> 304 K
macOS aarch64 468K -> 404K
AIX 2.5M -> 2.1M
The debuginfo files get smaller too by ~ 10 - 20 % (AIX has no separate debuginfo file that's why the large binary)

However for MSVC the SIZE optimization flags seem to be bad , the binaries get LARGER not smaller ! I opened https://bugs.openjdk.org/browse/JDK-8349214 .

MBaesken · 2025-02-05T13:44:51Z

(hint: Use e.g. make java.desktop-libs-only JOBS=1 LOG=info to get a build speed number that you can compare across compiler flag changes)

That does not work/compile, it leads to

make java.desktop-libs-only JOBS=1 LOG=info
Generating main target list
Running make as 'make JOBS=1 LOG=info java.desktop-libs-only'
Building target 'java.desktop-libs-only' in configuration '/myjdk'
Creating support/modules_libs/java.desktop/libawt.so from 72 file(s)
Compiling AlphaMacros.c (for libawt.so)
In file included from /myjdk/jdk/src/java.desktop/share/native/libawt/java2d/loops/AlphaMacros.h:29,
                 from /myjdk/jdk/src/java.desktop/share/native/libawt/java2d/loops/AlphaMacros.c:26:
/myjdk/jdk/src/java.desktop/share/native/libawt/java2d/loops/GraphicsPrimitiveMgr.h:36:10: fatal error: java_awt_AlphaComposite.h: No such file or directory

Seems the dependencies do not work for some reason, so I need to build the whole jdk with LOG=info I guess.

erikj79 · 2025-02-05T14:11:15Z

(hint: Use e.g. make java.desktop-libs-only JOBS=1 LOG=info to get a build speed number that you can compare across compiler flag changes)

Seems the dependencies do not work for some reason, so I need to build the whole jdk with LOG=info I guess.

Adding the -only suffix does indeed disable dependencies, so you have to manually set up your build directory state to have all the dependencies built already. This would be a reasonable sequence for getting relevant timings. First make sure all dependencies have been built:

$ make java.desktop-libs

Then delete only the things you want to rebuild and run the part of the build that is relevant. This can be repeated.

$ rm -rf build/<your-build-dir>/support/modules_libs/java.desktop
$ time make java.desktop-libs-only JOBS=1

JDK-8348830

fe3e66c

openjdk bot changed the title ~~JDK-8348830: LIBFONTMANAGER optimization is always HIGHEST~~ 8348830: LIBFONTMANAGER optimization is always HIGHEST Jan 28, 2025

openjdk bot added the rfr Pull request is ready for review label Jan 28, 2025

openjdk bot added build build-dev@openjdk.org client client-libs-dev@openjdk.org labels Jan 28, 2025

erikj79 approved these changes Jan 28, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 28, 2025

prrace approved these changes Jan 28, 2025

View reviewed changes

mrserb approved these changes Jan 29, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Jan 29, 2025

openjdk bot closed this Jan 29, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 29, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8348830: LIBFONTMANAGER optimization is always HIGHEST #23332

8348830: LIBFONTMANAGER optimization is always HIGHEST #23332

MBaesken commented Jan 28, 2025 •

edited by openjdk bot

Loading

bridgekeeper bot commented Jan 28, 2025

openjdk bot commented Jan 28, 2025 •

edited

Loading

openjdk bot commented Jan 28, 2025

mlbridge bot commented Jan 28, 2025

MBaesken commented Jan 28, 2025

prrace commented Jan 28, 2025

MBaesken commented Jan 29, 2025

MBaesken commented Jan 29, 2025

openjdk bot commented Jan 29, 2025

openjdk bot commented Jan 29, 2025

MBaesken commented Jan 29, 2025

magicus commented Jan 29, 2025

MBaesken commented Jan 30, 2025 •

edited

Loading

magicus commented Jan 30, 2025

MBaesken commented Jan 31, 2025

TheShermanTanker commented Jan 31, 2025

MBaesken commented Feb 3, 2025 •

edited

Loading

MBaesken commented Feb 5, 2025

erikj79 commented Feb 5, 2025

8348830: LIBFONTMANAGER optimization is always HIGHEST #23332

8348830: LIBFONTMANAGER optimization is always HIGHEST #23332

Conversation

MBaesken commented Jan 28, 2025 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Jan 28, 2025

openjdk bot commented Jan 28, 2025 • edited Loading

openjdk bot commented Jan 28, 2025

mlbridge bot commented Jan 28, 2025

Webrevs

MBaesken commented Jan 28, 2025

prrace commented Jan 28, 2025

MBaesken commented Jan 29, 2025

MBaesken commented Jan 29, 2025

openjdk bot commented Jan 29, 2025

openjdk bot commented Jan 29, 2025

MBaesken commented Jan 29, 2025

magicus commented Jan 29, 2025

MBaesken commented Jan 30, 2025 • edited Loading

magicus commented Jan 30, 2025

MBaesken commented Jan 31, 2025

TheShermanTanker commented Jan 31, 2025

MBaesken commented Feb 3, 2025 • edited Loading

MBaesken commented Feb 5, 2025

erikj79 commented Feb 5, 2025

MBaesken commented Jan 28, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Jan 28, 2025 •

edited

Loading

MBaesken commented Jan 30, 2025 •

edited

Loading

MBaesken commented Feb 3, 2025 •

edited

Loading