RFR: 8293116: Incremental JDK build could be sped up [v3]

Jan Lahoda jlahoda at openjdk.org
Fri Sep 9 11:41:08 UTC 2022

On Thu, 8 Sep 2022 13:54:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I looked up what kind of dependencies we are passing in through `DEPEND`. None, it turns out. It is not used. So that is not a worry. We might consider removing it. Sending in exceptional dependencies like that is never a good design decision. If it ever happens again that this would be the only acceptable solution, we can re-add the `DEPEND` argument.
>> But that basically mean that Jan's patch might be okay, after all. `DEPENDS` does not exist, and I want to remove it. `EXTRA_DEPS` is only modified if we change the `depend` javac plugin. I am willing to sacrifice automatic recompilation of all Java classes if that is changed.
> Ok I was wrong about what EXTRA_DEPS was used for, I read the code too hastily. However, the dependency declaration for the pubapi files from other modules is added in make/CompileJavaModules.gmk like this:
> $($(MODULE)_COMPILE_TARGET): $(foreach d, $(call FindDepsForModule, $(MODULE)), \
>     $(call SetupJavaCompilationApiTarget, $d, \
>         $(if $($d_BIN), $($d_BIN), $(JDK_OUTPUTDIR)/modules/$d)))
> So this still doesn't change my main point. The pubapi files only appear on the dependency declaration for `$($(MODULE)_COMPILE_TARGET)`. This means that with the current patch, we will not recompile the full module when a parent module has a change to the pubapi. The Depend plugin needs to see the pubapi files in `$$?` for that to happen.
> One could also make the case for using DEPEND when adding such a dependency instead of referencing `$($(MODULE)_COMPILE_TARGET)` in explicit rules. It would be more inline with more recent design patterns.

Hmm, how about this?

that seems to work (hopefully), although I am not sure if that is not breaking some overall concept in the build.


PR: https://git.openjdk.org/jdk/pull/10104

More information about the compiler-dev mailing list