-
Bug
-
Resolution: Fixed
-
P4
-
13
-
None
-
b16
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8242991 | 11.0.8 | Erik Joelsson | P4 | Resolved | Fixed | b01 |
JDK-8242752 | 11.0.7 | Erik Joelsson | P4 | Resolved | Fixed | b10 |
In JDK-8204551, exceptions.hpp started using THIS_FILE instead of __FILE__ to generate exception messages. This is causing the precompiled header to no longer provide any benefit on at least Linux/GCC. The problem is that the THIS_FILE macro is provided on the command line and is different for each compile unit. Because of this, it seems GCC invalidates the precompiled header completely.
My build time of just "make hotspot" went from 1m52s to 2m40s with this change. I've also noticed that the make dependency files for libjvm generated by GCC after this change have grown from 11M total to 25M total, which very noticeably increases incremental build performance from just make parsing time. My theory on this is that when GCC invalidates the precompiled header input, it adds all the headers included through precompiled.hpp to the list of make dependencies, where before, it would exclude them.
I discovered this while working onJDK-8217728.
There is a long history of THIS_FILE vs __FILE__ with different pros and cons, and I believe that to solve this properly, we need to take a step back and do some thinking. The main issue with __FILE__ is that it resolves to the complete filename as specified on the command line to the compiler. Since we use absolute paths, this means, __FILE__ will be absolute. We like using absolute paths since it makes our command lines copy-paste-able. It's a pretty deep set design principle in the build system. There are two problems with absolute paths.
1. It makes builds less reproducible unless you build in the exact same directories.
2. It leaks internal information from the build host into our binaries.
We introduced THIS_FILE to get around this. This macro is defined by the build system and takes the value of the C/C++ file being compiled, with no directories, just the filename. The biggest drawback with using this is that if THIS_FILE/__FILE__ is used in a header file, they are no longer equivalent. Now we also learn that at least GCC cannot handle command line set macros in precompiled headers.
We need to check other platforms to see what the impact of different solutions may be.
My build time of just "make hotspot" went from 1m52s to 2m40s with this change. I've also noticed that the make dependency files for libjvm generated by GCC after this change have grown from 11M total to 25M total, which very noticeably increases incremental build performance from just make parsing time. My theory on this is that when GCC invalidates the precompiled header input, it adds all the headers included through precompiled.hpp to the list of make dependencies, where before, it would exclude them.
I discovered this while working on
There is a long history of THIS_FILE vs __FILE__ with different pros and cons, and I believe that to solve this properly, we need to take a step back and do some thinking. The main issue with __FILE__ is that it resolves to the complete filename as specified on the command line to the compiler. Since we use absolute paths, this means, __FILE__ will be absolute. We like using absolute paths since it makes our command lines copy-paste-able. It's a pretty deep set design principle in the build system. There are two problems with absolute paths.
1. It makes builds less reproducible unless you build in the exact same directories.
2. It leaks internal information from the build host into our binaries.
We introduced THIS_FILE to get around this. This macro is defined by the build system and takes the value of the C/C++ file being compiled, with no directories, just the filename. The biggest drawback with using this is that if THIS_FILE/__FILE__ is used in a header file, they are no longer equivalent. Now we also learn that at least GCC cannot handle command line set macros in precompiled headers.
We need to check other platforms to see what the impact of different solutions may be.
- backported by
-
JDK-8242752 Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC
- Resolved
-
JDK-8242991 Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC
- Resolved
- relates to
-
JDK-8217728 Speed up incremental rerun of "make hotspot"
- Resolved
-
JDK-8204551 Event descriptions are truncated in logs
- Resolved
-
JDK-8220762 Rework EventLog message string handling
- Closed