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. ;\^)


    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.


    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.


    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.


Wednesday Aug 12, 2009

Anatomy of the JDK Build

The recent "javac -target 7" changes to the jdk7 repositories has prompted me to post this blog about OpenJDK builds. To those unfamiliar with Java classfile versions, each JDK release typically has upgraded the version of the classfiles created by the javac compiler, newer JDKs understand it's own classfile version, plus all the older versions. But older JDKs can NOT understand the newer classfile versions, and their javac instances will not understand how to create newer versions, which of course, makes perfect sense, not sure why I had to say that... oh well... The JDK itself usually contains the newest classfile version, however JDK6 delivered JDK5 classfiles. With JDK7 we want to deliver the latest classfile version in the JDK itself, so the way the JDK is built becomes more interesting to know.

See Alex's version blog, Joe's version blog, and Joe's build advice blog for more information.

When building the OpenJDK from scratch, there are 7 repositories involved, many different system components used in the build process, and an ordering or dependency chain.

For now I'll ignore the build variations or flavors of builds, such as product (optimized), fastdebug, and debug, which generally just repeat the same steps but with slight variations on how the bits are built. What I wanted to do here was describe the dependencies between the repositories and the bootstrap jdk used in the build.

Granted this could change, but currently building OpenJDK JDK7 sources from scratch happens in this order:

  1. The langtools repository (repository that holds javac, javah, etc.) is built first using the bootstrap jdk6 javac. This creates a bootstrap javac.jar compiler that can be run with the bootstrap jdk. This bootstrap javac.jar is capable of compiling and creating the newer jdk7 source and classfiles, e.g. it understand -target 7 and -source 7.

    Note that the langtools sources need to be jdk6 compiled sources, and when this repository is built, it also uses the bootstrap javac.jar to compile itself into -target 7 classfiles to be put into the final jdk7 image. Keep in mind that we cannot run jdk7 classfiles yet, we can create them using the bootstrap jdk and the bootstrap javac.jar, but we have no jdk7 image to run yet.

  2. The corba repository is built using the bootstrap jdk and the bootstrap javac.jar from the langtools build.
  3. The jaxp repository is built using the bootstrap jdk and the bootstrap javac.jar from the langtools build.
  4. The jaxws repository is built using the bootstrap jdk and the bootstrap javac.jar from the langtools build.

    Note that up to this point, these are jdk7 classes, but built with a jdk6 runtime (the jdk6 rt.jar classes). The jdk7 rt.jar has not been built yet. This has not been an issue in that the sources in corba, jaxp, and jaxws are restricted to jdk6 interfaces and have no need for jdk7 specific interfaces. This is also why a jdk5 cannot be used as the bootstrap jdk, jdk5 does not have all the interfaces needed by the above repositories.

  5. The hotspot repository is built using the native C++ compiler.

    Note that hotspot includes java source, however that source is currently compiled with the bootstrap jdk javac, not the langtools bootstrap javac.jar. This may need to change in the future, but there may be some requirements for using -target 6 or even -target 5 with whatever javac is used here.

  6. Lastly the jdk repository is built. This repository pulls all the above builds together, and also builds the rest of the jdk using the bootstrap jdk and the langtools bootstrap javac.jar. The actual javac included in the jdk7 image will have been the -target 7 built classes. Eventually it will have created enough of a jdk7 image that it could be run on it's own, at that point the demos are built and the image is finalized.

    Note that when building these jdk sources, they are built in a particular order defined by the Makefiles, and against themselves, so that in a sense, these classes are compiled against what will become the jdk7 runtime.

A really good test at this point is to use this newly built jdk7 as the bootstrap jdk, and build a second jdk7. It should work. The top level Makefile has an option to do this make SKIP_BOOT_CYCLE=false.

You can build each repository separately and most developers do, but now that we have this -target 7 requirement, you may need to specify the bootstrap jdk as jdk7, include the langtools repository as part of your build, or set ALT_LANGTOOLS_DIST to point to the langtools/dist directory (a built langtools repository).

Hope this helps to explain things a little. Please post any questions you have, I'll try and answer all I can. And hopefully Jonathan will keep me honest here. :\^)


Monday Jun 15, 2009

Warning Hunt: OpenJDK, NetBeans, Warnings, and FindBugs

Did you see Bill's FindBugs slides from JavaONE 2009? You should create some step by step directions on getting started with NetBeans, FindBugs and the OpenJDK. We need to get developers working on this.
Humm, Ok, I'll look into that.
Don't just "look into it", do it!
Ok ok already, I'll "do it".
And try and talk about how to fix warnings, and especially the FindBugs errors, maybe talk about some kind of best practices.
Yeah yeah, and I'll take care of the world peace problem too.
Smart ass, how did you ever get this job in the first place.
Everything else I wanted to do was illegal, creating software seemed like the most criminal thing I could do that wouldn't put be in jail.
Oh geez, why does this seem like a Dilbert comic? Get to work!
Aye aye Captain! Batton down the hatches, full speed ahead, we be looking for the White Whale...
"Drink, ye harpooners! drink and swear, ye men that man the deathful whaleboat's bow -- Death to Moby Dick!"
Oh for heavens sake, maybe you should look into a mental institution.

Ok folks here we go...

My sincere apologies to the Whales and Whale lovers out there, just remember Moby Dick is just a fictional story and I am in no way condoning the slaughter of those innocent and fantastic animals.

NetBeans, FindBugs, and Hunting Moby Dick

For a developer that wants to actually change the source code, the very best way to work with a tool like FindBugs is through an IDE.

  1. Get .

    Download and install NetBeans 6.5.1, I used the smallest "Java SE" version but any one of the "Java" versions will do. It installs quickly and easily. I would normally recommend the newer NetBeans 6.7, and I am trying 6.7 myself right now, but so far I have been unable to get the other steps below to work with 6.7, so I'd stick with 6.5.1 for now.

  2. Turbo charge it .

    Configure the NetBeans memory settings for the best performance, this is optional. See my NetBeans performance blog. Effectively we want to boost the memory sizes to improve the interactive experience. Of course, if you have less than 1Gb RAM, you may want to avoid this completely or adjust the -Xmx number down:

    Mac<1> mkdir -p ${HOME}/.netbeans/6.5/etc
    Mac<2> cat >> ${HOME}/.netbeans/6.5/etc/netbeans.conf
    netbeans_default_options="-J-Xms256m -J-Xmx768m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m
    -J-Xverify:none -J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC
    -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled"
    NOTE: Keep in mind that if you run FindBugs inside NetBeans as I am suggesting here, you may need to adjust the above -Xmx number even higher depending on what you are running FindBugs on (e.g. how many class files or the size of the jar file). Running FindBugs as a separate process allows you to avoid using NetBeans heap space, but you won't get the good integration with the IDE that I'm advertising here, and what I think you need to actively work on fixing the bugs. FindBugs does use up some heap space, just make sure you have enough.
  3. Get FindBugs .

    The NetBeans FindBugs plugin is a bit hard to find. You need to tell NetBeans where the UpdateCenter center is that has this plugin. The NetBeans plugin is not maintained by the FindBugs developers. To do this you need to start up NetBeans 6.5.1 and do the following:

    1. Select "Tools->Plugins".
    2. Select "Settings".
    3. Select "Add"
    4. Enter any name you want in the "Name:" field, and for the "URL:" field use:
      then select "OK".
    5. Select "Available Plugins", select the "SQE Java" plugin, select "Install", and go through the plugin install process.
    You should now see several new icons in NetBeans, specifically the icons for the SQE site , the FindBugs tool , and the PMD tool . My experience with FindBugs has been very positive and I trust this tool completely, rarely has it been wrong or given bad advice. On PMD, you will note that the PMD tool has the image of a gun in it's icon, for a good reason, be very careful with PMD, shooting yourself in the foot is pretty easy to do.
  4. Find a NetBeans project to play with. My first example is jmake, a small Java project available from Get yourself a clone with:
    hg clone ${HOME}/jmake
    Then use the NetBeans "Open Project..." to open up this directory ${HOME}/jmake as a NetBeans project. It should load up fine, build cleanly, and you can try using FindBugs to look at and even fix some of the bugs.
    Note: You need to be a developer member of the jmake project to push changes back.

    Or you can get sources, and either find a NetBeans project or create one. I chose to create one and picked the jdwpgen tool in the jdk/make/tools/ directory. So I did this:

    1. Cloned the OpenJDK sources (just a partial forest):
      hg clone ${HOME}/myjdk7
      cd ${HOME}/myjdk7
      hg clone
    2. Tell NetBeans to create a "New Project", pick "Java Project with Existing Sources", naming the project "jdwpgen", and I'll locate this throw away project at ${HOME}/jdwpgen, then select "Next".
    3. Then I tell it to use the source directory ${HOME}/myjdk7/jdk/make/tools/src/, and select "Next".
    4. Then I specify build/tools/jdwpgen/\*\* in the "Includes", and select "Finish" to complete the project definition. This process should work for any clean subset of Java sources in the OpenJDK, but I can't attest to that fact, yet.
    5. Try a build (should compile 50 files or so), run FindBugs, try and fix something.
      Note: You will need to be a member of the OpenJDK project and be able to create correct changesets to push changes back, this normally requires a BugID, and will require that certain changeset comment and whitespace rules are followed. (Yeah yeah, I know we are working on this, someday I'll be able to describe this better and it will all be open and completely logical ;\^). Anyone outside of Sun that has tried to push changes into OpenJDK will confirm how difficult this currently is, but we are working on it.

That's it, play with it, try fixing FindBugs errors or compiler warning errors. Aye, we didn't manage to kill Moby Dick, but we sure sunk in a few good harpoons.

Command Line Usage

The FindBugs and PMD tools can be run from the command line to create all kinds of reports. You will need to download and install FindBugs and/or PMD of course.

Some sample FindBugs command lines:

findbugs -maxHeap 512 -textui -effort:default -low -exitcode ${HOME}/jdwpgen/dist/jdwpgen.jar
findbugs -maxHeap 512 -textui -effort:default -low -exitcode -xml:withMessages -output ${HOME}/jdwpgen/build/findbugs.xml ${HOME}/jdwpgen/dist/jdwpgen.jar

Some sample PMD command lines: ${HOME}/myjdk7/jdk/make/tools/src text basic,imports,unusedcode ${HOME}/myjdk7/jdk/make/tools/src xml basic,imports,unusedcode > ${HOME}/jdwpgen/build/pmd_out.xml

I use the command line versions when I just want the data for statistic purposes or as part of a batch build process, which I'll talk about later.

Mac, NetBeans/Ant, and PATHs

FYI... anyone that works with Ant scripts (all NetBeans users) has found out that the best way to get the Ant <exec> to work well is to set PATH properly, but controlling PATH from a GUI launch is tricky. For the Mac see my previous post on NetBeans, Mac and PATHs, which explains the Mac tricks needed to set the PATH for NetBeans.

For Developers, Hudson IS The Answer...

Have you used Hudson? If you haven't, you should, I'll blog about it more very soon, but to get yourself started, do this:

  1. Download Hudson (hudson.war)
  2. In a separate shell window, run:
    java -jar hudson.war
  3. Go to http://localhost:8080/ and play with your very own Hudson, create a new job, browse the many plugins available,...

I'll talk about Hudson and how to connect it up to FindBugs, PMD, Warning Messages, etc. in a future blog...


Monday May 11, 2009

Fedora 9 and Mac VMware Fusion 2.0.4

UPDATE: (5/11/2009) Patches for openjdk6 were deleted from this blog, not needed any more if using the latest OpenJDK 6 sources.

Thought I would provide some notes on setting up a Fedora 9 VMware image on my Mac laptop using VMWare Fusion 2.0.4. I used the same steps for both Fedora 9 32bit (i386) and 64bit (x86_64), however I had some trouble with installing x86_64, even seemed to trigger a MacOS panic at one point after doing the yum update, not sure what that was all about, only happened once. This was strictly a local Fedora install, so I didn't need to deal with any of the networking issues of setting up a real physical machine.

I'll try and re-create the order of things as best I can:

  1. Create VMware Virtual Machine from Fedora 9 install iso image. I set it up to have a 20GB disk (You cannot change this disk size afterwards!). I'm using 768Mb RAM (512Mb caused slow builds) and during the install I asked for the "Software Development" packages.

  2. Update your system and make sure you have all you need. Logged in as root:

    yum install kernel kernel-headers kernel-devel
    yum install hg ksh tcsh csh cups cups-devel freetype freetype-devel lesstif-devel
    yum groupinstall "X Software Development" "Development Tools" "Java Development"
    yum update
    This will take a while. A reboot after you are all done would be a good idea.
  3. Install VMware tools. Once you extract out the VMware tools folder vmware-tools-distrib, once again logged in as root do the following:

    cd vmware-tools-distro
    The list of questions to answer is long and convoluted, mostly the default answer works fine, but in some cases it seems to think you are using a remote login and you have to say "yes" to continue the installation.
  4. Mouse problems: For some reason all my single clicks were being treated as double clicks, which drove me nuts. I found this posting which solved the problem, I use option 2 and edited the file /etc/X11/xorg.conf and added the following lines, logged in as root:

    Section "ServerFlags"
            Option      "AutoAddDevices" "false"
    A reboot of your virtual machine is necessary to fix this.
  5. The default limit on file descriptors is very low, to allow for a larger limit the following addition to the file /etc/security/limits.conf will increase that limit, again logged in as root:

    \* soft nofile 64000
    \* hard nofile 64000
    You need to logout and back in for these new limits to be available.
  6. Recently it was discovered that the upgraded kernel-headers package has trimmed down the files it delivers to /usr/include/linux/ (i.e. dirent.h) and although this doesn't impact OpenJDK building, it could impact builds of parts of the Sun JDK (plugin). So to avoid this missing include file problem, you have to do this last step because the above steps need the latest and matching kernel-headers files. To get the older kernel-headers package run:

    yum remove kernel-headers glibc-headers
    yum install kernel-headers-2.6.25 glibc-headers
    Bugs have been filed on the Sun JDK to see if we can break this dependency on the /usr/include/linux/ files.

That's the basic system setup. In addition I also setup my own home directory with the following so I can build the OpenJDK:

  1. Get webrev tool:

    mkdir -p ${HOME}/bin
    cd ${HOME}/bin
    chmod a+x webrev
  2. Get latest ant:

    mkdir -p ${HOME}/import/ant_home
    cd ${HOME}/import/ant_home
    tar -xzf apache\*.tar.gz
    mv apache-ant-1.7.1/\* .
  3. Get forest extension:

    mkdir -p ${HOME}/hgrepos
    cd ${HOME}/hgrepos
    hg clone hgforest
  4. Setup your ${HOME}/.hgrc file:

    cat > ${HOME}/.hgrc <<EOF
    username = ${USER}
    ssh = ssh -C
    groups = wheel
    clone = --pull
    fclone = --pull
    fetch = -m Merge
    ffetch = -m Merge
  5. Get OpenJDK7 sources (jdk7 build source forest):

    mkdir -p ${HOME}/hgrepos/jdk7
    cd ${HOME}/hgrepos/jdk7
    hg fclone jdk7-build
  6. Get OpenJDK6 sources (jdk6 master source forest):

    mkdir -p ${HOME}/hgrepos/jdk6
    cd ${HOME}/hgrepos/jdk6
    hg fclone jdk6-master

Now to see if I can build both OpenJDK7 and OpenJDK6:

# To get rid of a few sanity errors
export LANG

# My own private copy of ant
export ANT_HOME

# Use the JDK that is part of Fedora 9

# Add java and ant to the PATH
export PATH

# Go to the root of the jdk7 source forest
cd ${HOME}/hgrepos/jdk7/jdk7-build

# Build jdk7
#  Don't run javadoc, too slow, needs 1024Mb RAM minimum
make NO_DOCS=true

# Go to the root of the jdk6 source forest
cd ${HOME}/hgrepos/jdk6/jdk6-master

# Build jdk6
#  Don't run javadoc, too slow, needs 1024Mb RAM minimum
make NO_DOCS=true

SUCCESS! They both build.


Monday Dec 08, 2008

OpenJDK6 Repositories!

I see it! It actually exists! Yes Virginia, There Is a Santa Claus!

Actually that's a whale we saw in Alaska this summer. No I'm not trying to insult Santa. ;\^)

Seriously, we have our first cut at generated OpenJDK6 repositories:

You can browse all 7 repositories:

Or you can clone them, or do a forest clone to get the entire forest:

hg fclone yourjdk6
(See the OpenJDK Developer Guide for more information on how to setup Mercurial and the forest extension).

A few important notes:

  • These should be treated as experimental and read-only, official ones should be next week
  • They should match the contents of the OpenJDK6 source bundles, except:
    • No control directory, these files are in the top repository now
    • Previously you had to 'cd control/make && gnumake', now just 'cd . && gnumake'
    • README-builds.html is in the top repository, it's movement has created a little confusion in the changesets, ultimately we will have one copy.
  • Contributed changes should be documented in the changeset comments, if the contribution information is missing please let me know
  • These repositories were created from the TeamWare workspaces and a set of patches and documentation on those patches, we may have to re-create them. If we re-create repositories again, the old ones will not be related to the new ones. So any changesets you create with your clones should be viewed as temporary until the final repositories are put in place.
  • The hotspot repository may be completely replaced when we upgrade to HS14, so when that happens you may need to re-clone the hotspot repository.

Please let me know if you see anything wrong with these repositories.

The target date for official repositories is next week, once it is official we can add more changesets to correct problems, but we can't go back and change the changesets already created.



Various blogs on JDK development procedures, including building, build infrastructure, testing, and source maintenance.


« July 2016