Kelly O'Hair's Weblog (blogs.sun.com)
Wednesday Nov 25, 2009
Faster OpenJDK Build Tricks
Here are a few tips and tricks to get faster OpenJDK builds.
-
RAM
RAM is cheap, if you don't have at least 2Gb RAM, go buy yourself some RAM for Xmas. ;^)
-
LOCAL DISK
Use local disk if at all possible, the difference in build time is significant. This mostly applies to the repository or forest you are building (and where the build output is also landing). Also, to a lesser degree, frequently accessed items like the boot jdk (ALT_BOOTDIR). Local disk is your best choice, and if possible /tmp on some systems is even better.
-
PARALLEL_COMPILE_JOBS=N
This make variable (or environment variable) is used by the jdk repository and should be set to the number of native compilations that will be run in parallel when building native libraries. It does not apply to Windows. This is a very limited use of the GNU make -j N option in the jdk repository, only addressing the native library building. A recommended setting would be the number of cpus you have or a little higher, but no more than 2 times the number of cpus. Setting this too high can tend to swamp a machine. If all the machines you use have at least 2 cpus, using a standard value of 4 is a reasonable setting. The default is 1.
-
HOTSPOT_BUILD_JOBS=N
Similar to PARALLEL_COMPILE_JOBS, this one applies to the hotspot repository, however, hotspot uses the GNU make -j N option at a higher level in the Makefile structure. Since more makefile rules get impacted by this setting, there may be a higher chance of a build failure using HOTSPOT_BUILD_JOBS, although reports of problems have not been seen for a while. Also does not apply to Windows. A recommended setting would be the same as PARALLEL_COMPILE_JOBS. The default is 1.
-
NO_DOCS=true
Skip the javadoc runs unless you really need them.
Hope someone finds this helpful.
-kto
Posted at 12:05PM Nov 25, 2009 by kto in Java | Comments[5]
Subscribe!
Could we have NO_DEMOS too?
Posted by Martin Buchholz on November 25, 2009 at 02:49 PM PST #
Nice !
Would be very cool to have a maven config ready for openjdk as well. This would include subproject for each part of the JDK. Doing so, we might plug this to Hudson continuous buid ;-)
A long term project should be : remove as much as C code as possible and replace it with Java code. Goals are : increase portability, refactoring, improve performance by removing JNI barrier crossing. For instance, Toolkit and Event dispatching can be almost 97% done in Java.
This would also ease debug, continuous integration, etc ...
This goes into the same kind of job that Garry has done on Shark : ease portability.
Posted by bjb on November 26, 2009 at 12:40 AM PST #
Posted by uberVU - social comments on November 26, 2009 at 01:07 AM PST #
NO_DEMOS: I thought I responded once... my comment got lost???
The demos are part of the jdk image itself, so excluding them might be a problem in that the image would be incomplete. They are also the first use of the built jdk, so it sort of serves as a little test of your built jdk. Although, that isn't going to work in a cross-compilation setup... :^(
Is this primarily an issue with how slow the demos build? What if they built faster? :^)
-kto
Posted by Kelly Ohair on November 30, 2009 at 10:25 AM PST #
Maven: Sigh... If I only had the time.. (maven is not a simple thing)
Hudson: Maven isn't really required to use Hudson. But I could see it being helpful for a few things, not a great answer on Windows/Solaris when it comes to native compilers etc.
Native Code: Yes, less is better, no argument. Nice to have dreams. ;^)
-kto
Posted by Kelly Ohair on November 30, 2009 at 10:29 AM PST #