Older blog entries for Anthony (starting at number 11)

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:

/* 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 ();

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.

During a recent visit to my parents, I upgraded their win95 box to use Mozilla Thunderbird and Firefox by default. This is a real milestone for me since it's the first time I've felt comfortable promoting free software solutions to this particular pair of senior citizens. Real problems are being solved: Thunderbird's spam filtering handles the unbelievable quantities of spam they receive, and Firefox can render modern web sites that the win95 compatible IE can't. Upgrading to XP wasn't even an option, since it won't install on their IBM Aptiva. Hurray for Free Software!

java benchmarks

I really need to update my java benchmarks page now that GCC 3.4 and mono beta 1 are available. Today I found a benchmark that tests thread creation/destruction and I/O that runs almost 4 times faster with gij than IBM's JVM. Definitely one for my fair and balanced benchmark list...

30 Apr 2004 (updated 30 Apr 2004 at 14:03 UTC) »

I saw Tim O'Reilly speak the other day. He pointed out some features of amazon.com that I never really took notice of before. And without further ado, I present Music to hack GCJ to.

Last week I started hacking distcc into my remote compilation monster. Rather than try to create clean patches, I'm just hacking like a madman. The build server now requests files from the client during the build process, as in my previous experiment. Still plenty to do, but it's looking neat.


28 Apr 2004 (updated 28 Apr 2004 at 20:48 UTC) »
Banner day

Yesterday Frank Eigler flew me from Raleigh to Toronto in his twin engine plane, a Piper Aztec. It was my first trip in a small plane, and wow - what an experience. This is what you see out the window. A little in-flight incident gave Frank an opportunity to show off what a cool cat he can be under pressure. Three cheers for twin engine planes and quick thinking!

Earlier in the day I attended a face-to-face meeting of Red Hat gcj users and hackers (including tromey, aph, bryce, gbenson, fitzsim and more), so it was a real banner day.

Here's a screenshot of a functional prototype of a distributed compilation tool that supports gcj. The server is running in the bottom window. The client in the top window establishes a connection to the server, and shuttles over files from the local filesystem on demand (driven by the LD_PRELOAD hack). The newly released OpenTNL project made this possible.


Red Hat is having another world-wide company meeting in Raleigh, NC starting this weekend. Among other things, this means that all the Red Hat gcj hackers/users will get to meet face-to-face for the first time in a while. I'm looking forward to seeing everyone.


This is the nickname for my LiveCD experiment. Everything is working well enough now that it's basically useful as a distcc server. Just pop it in a cdrom and it goes. Now I've been thinking of how to support remote native compilation of java code with gcj. The distcc approach doesn't work because it depends on sending preprocessed source with no external dependencies to the build machine. This won't work with gcj, so my current thinking is to just hook into the build machine's C library by LD_PRELOADing a library like this in order to generate queries back to the user's machine for other sources (jar, class, etc). Will this work?

I like this approach, even for C/C++, since it may enable speculative compilation on the build machines during idle times (different debug or optimization levels).

Why Managed C++ on mono with Open64 will fail

I was going to leave it at one blog entry today, but it seems that blogs are the only forum in which to respond to other blogs.

Miguel de Icaza's recent blog entry on Managed C++ and Mono is really misguided. He proposes that Open64 and the old "new" WHIRL representation present a path to Managed C++ on mono. I attended the Open64 User Forum last year, and this is what I learned. Some of it may be dated now, but a quick look at the mail archives is unconvincing.

  • Open64 has a fractured developer community.
    The open source community around Open64 technology forked a number of years ago (see ORC), so there doesn't appear to be canonical upstream sources anywhere. And while a couple of big companies are still building production compilers based on the Open64 technology, there is no meaningful interaction with the open source community ("where do we send patches?" was an oft heard refrain).
  • Open64 has a small user community.
    This compiler has no x86 back-end, which severely limits the potential user community. I believe that this really inhibits the ability of the non-commercial developers from producing a trusted compiler.
  • The GNU compiler front ends hacked into Open64 are way old.
    This is where I'd expect you'd want to borrow the most code for a Managed C++ tool. But don't expect help from the GCC community to fix this. The FSF has decided that the technology used in Open64 (persistant intermediate representations) is harmful to their goals.
I don't really mean to be so harsh on the Open64 project. In many ways, the technology is a decade ahead of GCC, and a number of successful commercial compilers have been built out of it -- but it is not a successful open source project. The only measure by which you might claim it is successful is as a research platform for generating interesting papers. And now GCC is bound to catch up in that arena, given the new SSA-based infrastructure.

So, if you really cared about Managed C++, then you would look to GCC and the new SSA infrastructure for an answer. On the other hand, you might just want to consider GCJ and CNI.

Shared libraries and "the desktop"

With all of the recent discussion of GNOME desktop programming technologies, I'm really surprised that ability-to-generate-shared-libraries doesn't ever come up. I mean, really. Take a look at some of these library sizes:

  • GNU Classpath
  • java-gnome
  • Xerces, xalan and friends
Now imagine a number of featureful applications jitting their own copies of these things (or just loading their non-shared AOT compiled assemblies). Not a pretty picture.

This is just one more reason gcj rocks.

Work and taxes...

...have consumed much of my time this past week. I dropped the ball on some of my free-time-hacking comittments (sorry Mark :-) However, I did find a few minutes to mess with...

LiveCD experiment

distcc is installed, and it appears to work. I've even got tomcat starting up and serving the start of a nice web app. The tomcat in Fedora is pretty cool. I was able to drop a third party JSP tag library into the right place and it just worked. The only complicated bit (for me, at least) was figuring out all of the various apache and mod_jk2 configury. It probably would have been much easier had I read instructions somewhere.

2 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!