First webrev for smart javac wrapper

Fredrik Öhrström fredrik.ohrstrom at
Tue Jul 10 15:20:35 PDT 2012

The current build-infra/jdk8 forest can now be configured using --enable-sjavac

This causes the build to do proper incremental builds of Java sources (all the other
sources are already properly handled when building incrementally)
i.e. only the java sources that need to be compiled are actually compiled.

Dependency tracking causes other packages that import from the recompiled
package to be recompiled, but >only< if the public api of the first package was

It also attempts to use multiple cores, i.e. start a JavaCompiler per core.
These compilers do currently not share any state at all! This is something
that we should improve upon in the future.

It spawns a background javac server in which all sjavac compilations take place.

Tested on linux32, linux64 and macosx64. 
Building on my workstation, 8 cores, 16GB RAM, SSD, fully primed ccache.

-- Build times ----------
Start 2012-07-10 23:39:19
End   2012-07-10 23:42:20
00:00:08 corba
00:01:10 hotspot
00:00:07 jaxp
00:00:10 jaxws
00:00:53 jdk
00:00:33 langtools
00:03:01 TOTAL

When building with an empty ccache:
-- Build times ----------
Start 2012-07-10 23:43:58
End   2012-07-10 23:52:57
00:00:08 corba
00:06:21 hotspot
00:00:08 jaxp
00:00:10 jaxws
00:01:38 jdk
00:00:34 langtools
00:08:59 TOTAL

The jdk build is slower since the sjavac server shuts down because of inactivity during the hotspot build.
The cost of re-optimizing the byte code is apparent. The timeout can of course be adjusted, or prevented.

After you built the jdk, add a public method foo to javax/management/ and do make again. 
You will see (and some javac warnings, here redacted):

Compiling BUILD_JDK
Package  pubapi has changed!
Compiling com.sun.jmx.interceptor(2) com.sun.jmx.mbeanserver(31) com.sun.jmx.remote.internal(14) com.sun.jmx.remote.protocol.iiop(4) com.sun.jmx.remote.protocol.rmi(2) com.sun.jmx.remote.util(5) 
Compiling ClassLoadingImpl.c
Compiling FileSystemImpl.c
Compiling Flag.c
Compiling GarbageCollectorImpl.c
Compiling GcInfoBuilder.c
Compiling HotSpotDiagnostic.c
Compiling HotspotThread.c
Compiling MemoryImpl.c
Compiling MemoryManagerImpl.c
Compiling MemoryPoolImpl.c
Compiling ThreadImpl.c
Compiling VMManagementImpl.c
Running rmic -v1.2 -iiop for
Running rmic -v1.2 -keepgenerated for
Running rmic -iiop -standardPackage for

The pubapi change in triggered a recompilation of other packages importing from,
(it does not track dependencies between java source files, only between java packages.) 
Then the recompiles of files with native methods, regenerate the c header files, and this triggers the recompilation
of the C-sources that include these header files. Clearly in this case, the header files should not be regenerated
since the native api has not changed, but that feature is waiting to be built into the smart javac file manager.
(ie not write non-changed headers to disk)
And finally it regenerates the rmi code related to the management api.

The first webrev is here.
Awaiting feedback to create the next webrev!


-------------- next part --------------
An HTML attachment was scrubbed...

More information about the compiler-dev mailing list