ecj: Your New Favorite Tool

A few days ago I 'finished' the proper rhug integration of Ant and the java bytecode compiler hidden within Eclipse. When built with gcj, I believe we end up with the absolute fastest java bytecode compiler in the world (yes, faster than jikes). gary was speechless.

Unfortunately, it requires a little tweak to GCC. If you're tenacious, or jh-build enabled, then you should be able to enjoy ecj yourself.

geeking out

I finally set up a wireless network at home. I was mainly interested in not having to run a long cable to the hacked TiVo anymore. But when I realized that my stereo system would have a wireless ethernet bridge behind it, I caved and picked up an AudioTron on the way home today. A friend of mine recommended the squeezebox, but I like the internet radio feature of the AudioTron. Both work with Linux servers. The squeezebox uses a server app written in Perl and the AudioTron just scans Windows shares (provided by Samba in my case). Highly recommended!

sbb

Strangers are asking me for updates on this, so.. here goes. I got a little distracted this past week with travelling (Chicago & Dallas), FC2 upgrades, and rhug hacking to do much. fitzsim pointed me at sqlite, which I'm now linking to my hacked distcc server in order to map file open requests to local filenames. Seems OK so far. Still lots to do.

random compiler thought

It seems that it should be possible to write a __builtin_memoize() function for GCC. It would take function pointer and return one that would act as a memoizing version of that function. Kind of cool, but useful? Dunno.

javascript and gnome

fitzsim recently got jhbuild working with gcj and java-gnome. I tried it out today, and created jhbuild support for rhug packages. Then I wrote my first gnome app in javascript:

#!/home/green/install/jhbuild-inst/bin/js
 
/* The java-gnome libraries need to be linked differently.
   Let's force lib-org-gnu-glib into memory first until this is fixed. */
java.lang.Class.forName ("org.gnu.glib.GObject");
 
/* Initialize the UI.  */
args = java.lang.reflect.Array.newInstance (java.lang.String, 0);
Packages.org.gnu.gnome.Program.initGnomeUI("First", "0.1", args);
 
/* Create our application, and enter the main loop.  */
app = new Packages.org.gnu.gnome.App("First", "First App");
app.show ();
Packages.org.gnu.gtk.Gtk.main();

Lots of neat things are happening here. I'm running the mozilla rhino JavaScript implementation, which supports LiveConnect for easy access to the gcj runtime. When my program refers to java-gnome classes, the system class loader knows to dynamically load java-gnome code in shared libraries with magic names (lib-org-gnu-gnome.so, etc).

This brings me to my first of several annoyances with java-gnome. They currently use .so names like libgnomejar2.7.so. This works fine if you're building executables and don't mind linking directly to those libraries. However, if you want to support dynamic discovery and loading of these classes you'll want to use the special naming conventions described in the gcj manual. I worked around this problem with a few symlinks.

There were a few more annoyances with java-gnome, but they are all minor and easily fixable. I'll follow up with those guys soon.

All this software was built with my tweaked jhbuild. I sent my changes to fitzsim, who is also trying to push his changes upstream.

tree-ssa merge day

Today is the day that Diego is merging the tree-ssa branch of GCC into mainline.

Here's a brief description of Static Single Assignment. My introduction to SSA form came in the early '90s when I developed a programming environment for a 3D information animation system using SSA based optimizations. The decision to use SSA form was a no-brainer since virtually all optimization algorithms being published back then (and since) assumed you were starting from SSA form. So why wasn't GCC using it?

GCC had grown up using its own low-level internal representation called RTL. And while SSA form saw a sudden explosion in popularity, migrating GCC over to use SSA was going to be a massive effort - more than anyone was willing to invest in themselves. Eventually Red Hat found themselves in a position to put the requisite resources to bear and, once the ball was rolling, support from the rest of the GCC community grew strong.

So this has really been a long time coming for GCC. Just getting this far has taken several man years of effort, and there's still a lot of work to do. Now that GCC has the basic SSA infrastructure in place, the focus will be on replacing (or supplementing) the old, low level RTL based optimizations with SSA versions.

For gcj, this means that we're finally getting some decent infrastructure to build important java-specific optimizations around (escape analysis, array bounds checking removal, etc).

Congratulations to all the hackers and backers who made this possible.

robilad's recent entry points to an old article by Marc Fleury that includes the following:

"Several people have suggested that JBoss is infringing Sun's copyrights by incorporating some of Sun's code into JBoss. We have carefully reviewed the JBoss code base and are confident that, with the exception of seven jars, all code distributed with JBoss was independently written by JBoss project contributors. As for those seven jars, that code was licensed from Sun under Sun's Binary Code License Agreement, which provides that JBoss can distribute that software in binary code format only. JBoss is fully complying with the terms of that license. "

JBoss version 3.0.4 (released much later than that article) included three source files in jboss-3.0.4-src/security/src/main/javax/security/auth containing Sun copyright notices. The build instructions read:

| Unjar the jaas.jar into the build.classes dir so that we can replace
| the javax.security.auth.login.LoginConfig class with one that uses
| the thread context classloader for LoginModules -->

It looks like they were patching Sun source code for whatever reason. IANAL, but my reading of the JAAS binary code license tells me that they shouldn't be doing this.

Well, this is what my notes tell me at least. Verifying this might be difficult, since the sources for the 3.0.4 release appear to be absent from the download page. I suppose I could be wrong.