On 30/04/2016 5:53 PM, Alan Bateman wrote:
On 30/04/2016 08:32, David Holmes wrote:
Just to add my concerns here, I was changing the launcher and building
images and that caused the jmods to be rebuilt as well. I would not
expect that so do we have missing dependency information in the build?
By "changing the launcher" then do you mean the native code, say in
jdk/src/java.base/share/native/? There are many modules with native
launchers and the launcher code is compiled for each one. If you instead
mean LauncherHelper or other java code then it's in java.base and so the
classes in that module need to be recompiled and of course everything
depends on java.base.
The native code - java.c. Can't see any reason for jmods to be recreated
every time I recompile that!
As regards the jmod files then they are the packaged modules. The linker
consumes these so they need to be built before we create the images.
Also the packaged modules are copied into the `jdk` image (by jlink) as
it is needed to create custom images.
Sure. But they shouldn't need to be recreated unless something relating
to their content has changed.
Cheers,
David
Anyway points to mention:
1. The jmod files are currently huge. This is mostly because of debug
info. Erik fixed this recently in jdk9/dev via JDK-8155632 but it may
not have got to all forests yet.
2. We have changes coming (should be in jdk9/dev by mid next week) that
avoids the need to generate the packaged modules in reverse topology
order. This is the change to the where the integrity hashes are recorded
that I mentioned in the first reply. This may help with the build times
a bit although generating the packaged modules is I/O bound so mileage
may vary.
-Alan
