Thanks for all the reviews, but unfortunately I wasn't satisfied with
the below solution. The combination of the buildjdk and interim-image is
getting really complex, and adding the optimize step is not making it
easier. Here is what I think is a good solution. It should be more
correct and also retain as much opportunity for concurrency as possible.
http://cr.openjdk.java.net/~erikj/8167195/webrev.01/
I tried to clarify each of the hard to understand dependencies with
thorough comments.
/Erik
On 2016-10-05 17:47, Erik Joelsson wrote:
Hello,
Please review this small patch, which should fix an issue introduced
by JDK-8166948. At least on Windows, running jmod on the exploded
image may fail if the new optimization target is running concurrently.
I had missed adjusting the dependencies for the jmod targets.
Bug: https://bugs.openjdk.java.net/browse/JDK-8167195
Patch:
diff -r 4bd1866d819b make/Main.gmk
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -615,15 +615,19 @@
$(foreach m, $(LAUNCHER_MODULES), $(eval $m-jmod: $m-launchers))
$(foreach m, $(COPY_MODULES), $(eval $m-jmod: $m-copy))
- # Jmods cannot be created until we have the jlink tool ready to
run, which requires
- # all java modules to be compiled and jdk.jlink-launchers.
- # And we also need to copy jvm.cfg (done in java.base-copy) and
tzdb.dat (done in
- # java.base-gendata) to the appropriate location otherwise jimage,
jlink and jmod won't start.
+ # Jmods cannot be created until we have the jlink tool ready to
run. During
+ # the build we run it from the exploded image. To be runnable, all
java
+ # modules and jdk.jlink-launchers need to be built. We also need to
copy
+ # jvm.cfg (done in java.base-copy) and tzdb.dat (done in
java.base-gendata)
+ # to the appropriate location otherwise jimage, jlink and jmod
won't start.
$(JMOD_TARGETS): java.base-libs java.base-copy java.base-gendata
jdk.jlink-launchers
- # When creating a BUILDJDK, the java compilation has already been
done by the
- # normal build and copied in.
+ # The above is enough when creating a BUILDJDK since the java
modules have
+ # been compiled by the normal build and copied in. In the normal,
non cross
+ # compiling case, jmod execution has to wait until the exploded-image
+ # is completely done. Otherwise the optimization target may be
changing
+ # module-info.class files while a jmod instance is trying to read
them.
ifneq ($(CREATING_BUILDJDK), true)
- $(JMOD_TARGETS): java
+ $(JMOD_TARGETS): exploded-image
endif
ifeq ($(CREATE_BUILDJDK), true)
/Erik
