-
Enhancement
-
Resolution: Fixed
-
P4
-
20
-
None
-
b09
Observe the logs and build times for two consecutive `make images` invocations. You will notice that hotspot is always recompiled.
It is seen more clearly with:
```
$ sh ./configure --with-debug-level=fastdebug --with-boot-jdk=/home/shade/Install/jdk18u-ea/; make clean; make hotspot; echo "===== REBUILDING NOW ====="; LOG=info make hotspot
...
===== REBUILDING NOW =====
Generating main target list
Running make as 'make hotspot'
Building target 'hotspot' in configuration 'linux-x86_64-server-fastdebug'
Building JVM variant 'server' with features 'cds compiler1 compiler2 epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc'
Compiling arguments.cpp (for libjvm.so)
Compiling abstract_vm_version.cpp (for libjvm.so)
Generating symbol list from object files
Creating mapfile
Linking libjvm.so
Copying jdk/lib/server/libjvm.so
Creating symlink jdk/lib/server/libjvm.debuginfo
----- Build times -------
Start 2022-07-18 19:14:26
End 2022-07-18 19:14:44
00:00:18 TOTAL
```
Remarkably, this does not happen in current JDK 19, which suggests this is a recent "regression". Bisection points toJDK-8288396. After that patch, the -Xinternalversion of two consecutively built binaries are:
```
$ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.shade.jdk) for linux-amd64 JRE (20-internal-adhoc.shade.jdk), built on 2022-07-18T17:42:31Z by "shade" with gcc 9.4.0
$ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.shade.jdk) for linux-amd64 JRE (20-internal-adhoc.shade.jdk), built on 2022-07-18T17:43:26Z by "shade" with gcc 9.4.0
```
...which shows different timestamps.
Reproducible builds seem to require setting the build timestamp explicitly, and providing `--with-hotspot-build-time=YOLO` at configure resolves the issue. Arguably, rebuilding without any source changes should not update the timestamp. Current (new) behavior seems to *break* reproducibility now: the binary gets updated always.
This seems to be becauseJDK-8288396 moved the timestamp to `CFLAGS_VM_VERSION`, which changes even with clean rebuild. Looks like the old way of doing `__TIME__` macro straight in `abstract_vm_version.cpp` made it immune to rebuild changes.
Maybe the way out is to default to "--with-source-date=current"?
It is seen more clearly with:
```
$ sh ./configure --with-debug-level=fastdebug --with-boot-jdk=/home/shade/Install/jdk18u-ea/; make clean; make hotspot; echo "===== REBUILDING NOW ====="; LOG=info make hotspot
...
===== REBUILDING NOW =====
Generating main target list
Running make as 'make hotspot'
Building target 'hotspot' in configuration 'linux-x86_64-server-fastdebug'
Building JVM variant 'server' with features 'cds compiler1 compiler2 epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc'
Compiling arguments.cpp (for libjvm.so)
Compiling abstract_vm_version.cpp (for libjvm.so)
Generating symbol list from object files
Creating mapfile
Linking libjvm.so
Copying jdk/lib/server/libjvm.so
Creating symlink jdk/lib/server/libjvm.debuginfo
----- Build times -------
Start 2022-07-18 19:14:26
End 2022-07-18 19:14:44
00:00:18 TOTAL
```
Remarkably, this does not happen in current JDK 19, which suggests this is a recent "regression". Bisection points to
```
$ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.shade.jdk) for linux-amd64 JRE (20-internal-adhoc.shade.jdk), built on 2022-07-18T17:42:31Z by "shade" with gcc 9.4.0
$ build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xinternalversion
OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.shade.jdk) for linux-amd64 JRE (20-internal-adhoc.shade.jdk), built on 2022-07-18T17:43:26Z by "shade" with gcc 9.4.0
```
...which shows different timestamps.
Reproducible builds seem to require setting the build timestamp explicitly, and providing `--with-hotspot-build-time=YOLO` at configure resolves the issue. Arguably, rebuilding without any source changes should not update the timestamp. Current (new) behavior seems to *break* reproducibility now: the binary gets updated always.
This seems to be because
Maybe the way out is to default to "--with-source-date=current"?
- relates to
-
JDK-8288396 Always create reproducible builds
- Resolved