Thanks for the explanation Erik.
I have taken a pass over the changes, and they look ok to me ( I am
happy to be listed as a reviewer ). I also did several build and test
runs on Solaris, Linux, Max OSX, and Windows. All look good.
I am seeing, in some cases, about a 20% reduction in image build times
on an 8 core i7, running Linux x86.
One question; Are there any new requirements on build systems as a
result of these changes?
-Chris.
On 13/08/14 13:03, Erik Joelsson wrote:
I should probably write something about the rather extensive changes to
the build logic in this patch.
As the source gets organized around modules, it made sense to also
organize the build more around modules. In this patch, the makefiles
have in large parts been split into module specific files and the top
level targets are oriented around modules. This means the top level
targets are much more fine granular than currently in JDK 9.
Another difference is that the top level targets are now able to run
concurrently, to give more opportunity for utilizing multiple cpus. In
JDK 9, the build moves sequentially through each repository, in a given
order, now make is free to run more things in parallel. This makes the
build faster, at least on beefy hardware. The drawback is that the build
log gets a bit more confusing. When something fails, it won't interrupt
other building threads at once, so the actual failure may be further up
the log (even further than before). I have found that searching for
"Error 2" is a good way to find the real failure. Another consequence is
that the build time summary at the end only displays total time as there
is no good definition for how much time was spent in each repository
anymore.
A summary on the new targets:
make [default]
Does pretty much the same as before. It compiles everything but does not
build all jars or create images.
make all
Builds everything, including jars, images and docs. Also runs a
verification tool on the java classes which will point out any broken
module boundaries.
make images
Same as before
make hotspot
Builds the hotspot repository, like before.
make docs
Builds all the documentation, including javadoc.
make docs-javadoc
Builds just the javadoc. This target has very few prerequisites so
provides a fast way to just build javadoc.
make gensrc
Runs all source code generation steps.
make java
Compiles all java classes.
Other similar targets are libs, launchers, gendata and copy
make java.desktop
Compiles everything in the java.desktop module (and its dependencies),
both java and native code. Works for any module name.
make java.desktop-java
Compiles the java classes in java.desktop (and its dependencies). Works
for any module name (and -gensrc, -libs, -launchers, -gendata, -copy)
In addition to this, the suffix -only can be added to any target to
disable the prerequisites for it. Using this is not recommended but it
may save time when doing certain incremental builds and you are in a
terrible hurry.
For incremental builds, sjavac can be used and works reasonably well
(configure --enable-sjavac). Work is in progress on making it work even
better. The old workaround JDK_FILTER=package/to/compile is still working.
The clean target is still oriented around repositories, mostly because
the build output is still in large parts repository oriented. This is
something we hope to improve later.
/Erik
On 2014-08-12 16:10, Chris Hegarty wrote:
This is a review request for the Initial changes for JEP 201: Modular
Source Code [1].
There are a number of individuals responsible for these changes. Some,
possibly not all, are explicitly listed in the To section of this
mail, and they will help address any comments arising from this review
request.
For the purposes of review, the actual source file moves have been
omitted from the webrev below, with the exception of any source file
that has a change to it’s actual content. The new location of the
source files can be determined from JEP 201 [1] and JEP 200 "The
Modular JDK" [2], or by browsing the staging forest [3].
Webrevs:
http://cr.openjdk.java.net/~chegar/8054834/00/
Due to the significant impact of these changes, a JDK 9 promotion has
been tentatively reserved for their integration. All comments are
welcome, although given the nature of the changes then we might have
to create separate issues in JIRA to address some of them later in
jdk9/dev..
-Chris.
[1] https://bugs.openjdk.java.net/browse/JDK-8051619
[2] https://bugs.openjdk.java.net/browse/JDK-8051618
[3] http://hg.openjdk.java.net/jigsaw/stage
