Archive for October, 2004


I’ve been doing a lot of debugging lately. I am very unhappy
with the current state of debuggers.

For instance, right now I’m looking into a code generation bug in
gcj. I’m debugging the generated code to understand what is going
wrong. I want to set a breakpoint in a function that is called just
before the failure, since I think perhaps this function is computing
something incorrectly. However, this function is called thousands of
times. What I’d like to do is set a breakpoint that is conditional on
who is calling my function — but of course this isn’t possible. (Cue
some evil hack involving looking at the frame pointer…)

People have talked about scriptable debugging for years, but we’re
still stuck with gdb’s lame not-quite-a-language. Ugh. Meanwhile I’m
spending the day like an interpreter, repeatedly hitting “continue;
up” until I see what I want. I should probably just write some elisp
and let Emacs do it.


Debugging gcjx has been mixed. On the one hand, gdb’s C++ support
is lacking in some ways, so certain bugs have been very hard to debug.
On the other hand, gcjx tracks locations for all the objects it builds
in its model. This means it is very easy to, say, put a breakpoint in
the code generator that triggers when gcjx is generating code for a
particular line in the original source code. I never did find a way
to do this reliably while debugging the old gcj. (Cue someone to clue
me in.)

This feature of gcjx turned out to be handy for debugging by
accident. Still, it puts me in mind to design in debugger support
features like this in my next program.

GCC Update

Geoff posted an
interesting plan
for GCC. The ensuing conversation pointed out
that, if we do this, we might as well just use LLVM. Anything that gets us a JIT
and the potential ability to remove libffi (if you have a JIT, then a
back end port can simply be reused to provide the same functionality)
is fine by me.

Class files

Jeroen was in town on
Saturday and we had a long and interesting talk. He pointed out that
the new 1.5 class file format PDF is available on the web, and I found
. This came at the right time since rewriting the class
reading code was the last thing to do before I could relicense gcjx to

libgcj hacking

I’ve basically got Eclipse 3 working now, though it is still a
bit of a pain to actually get it to run. This will get easier as the
GCC 4.0 release nears.

Today Andrew sent me a patch to implement the class cache idea —
we map class hashes to the name of the corresponding .so. This worked
fine and let me compile random bits of Eclipse 3 (using the BC
compiler with the new verifier) and have it all work with no
application changes at all. Cool stuff.

Java Testing

Today we moved the repository for the Jacks java compiler testing
project into the Mauve
cvs repository. Mauve has come a long way since Anthony and I started
it all those years ago, and with the addition of Jacks it is probably
the most comprehensive free test suite for the core of a Java

The only missing bit seems to be VM-level testing. The verifier
tests provide a little of this, and the binary compatibility tests
provide a little more, but really we could use a concerted effort to
test all the various constraints on the VM. Probably should steal
code from the kaffe distribution…

I would propose renaming Mauve to the Free Compatibility Kit,
except the acronym is too vulgar :-).

Free Java Summit

There’s been planning internally at Red Hat for a while to host a
Free Java Summit. This is a reality now, it will be happening
November 18 and 19 in Boston. The agenda is still in a state of flux,
but I gather one of the main focuses will be promoting better
cooperation, unity, and information sharing in the free java space.

The summit is invitation-only, but I was told that community types
are welcome — so if you are a free java hacker or fellow traveler,
and you want to come, let me know and I will pass the information to
the list-keepers. I probably can’t say much about the attendee list
at the moment, but it will be a good cross-section of academia,
industry, and the free software community.

Eclipse Plugins

Today Red
Hat released
a couple new Eclipse plugins — one for RPM hacking
and one for using OProfile from inside Eclipse. This is some cool

Movie Editing

From time to time, Anthony and I work on a
movie editor. It is between names at the moment, so no nice tag line,
but we do have a
first screenshot
(looks like I broke thumbnail generation in this
one, bleah).

The first thing you’ll notice is that it is an Eclipse plugin.
While almost everyone I’ve talked to agrees that this is a crazy idea,
to me it makes a lot of sense, as Eclipse provides a lot of nice
facilities. We get to write in a high level language, and Eclipse
provides a lot of core support for writing applications — the kind of
things I had hoped, back in the day, that libgnomeui would provide.

It seems to me that editing a movie isn’t too different from
developing a program, and Eclipse makes it very easy for us to exploit
this. E.g., we already have CVS integration, and media files, which
you probably wouldn’t store in CVS, are easily handled as linked
resources. As another example, if you wrote an effects plugin, you
could easily have your movie project depend on the plugin, so that a
complete rebuild would first build the effect, then the movie would
apply it. This could all be done inside Eclipse — changes to the
effect would cause the movie to be re-rendered.

More on the state of this, and our plans, and justifications for
and benefits of using Eclipse, later. If you’ve got a good idea for a
name, that isn’t cutesy, send it my way :-). Maybe I’ll also post a
bit about our long search for an appropriate media framework — or
maybe I can get Anthony to write about that.


I downloaded Croquet today to give
it a try. This didn’t work out very well, but I’m still optimistic
about this project. For one thing, this eliminates my need for a
gdb/irc interface, by adding collaboration to the whole desktop. The
screen shots look super-cool, the 3D-ness makes me immediately think
that lack of screen real estate won’t be a problem again.

I really find this project inspiring — it has reawakened some of
my interest in GUI hacking, which has long been dormant. I’d love to
see this ship as the default UI in, say, FC5 :-).


We’re probably going to fork Jacks,
though nobody will know about it since my email never makes it to the
list. I’ve written a few simple tests for new language features and
put them in my own private copy. I did a little bug fixing in gcjx,
too. On the tree front, I wrote an article about writing GCC front
ends, the thesis of which is that it is way easier than you have
heard. More on that later.

gcjx hacking

Telling the gcc world about gcjx, so far, has been a painless
process. I’ll be making my branch sometime pretty soon, maybe this

In the meantime I made boxing, unboxing, varargs, and static
import work. That means that all the easy additions to the language
are working. Now on to fix up the harder things. I got a burst of
energy for this since Mark pointed me at a non-click-through way to
see the JLS3 (complete with change bars).

The algorithm for handling generic methods is several pages of
notation, it reads like a math text. One wonders if this isn’t


Some day, if I’m super motivated, I’ll hook gcjx up to LLVM. Well, maybe someone else
will. I’m actually more interested in LLVM’s potential to provide a
JIT for libgcj. That seems stalled on exception handling (the problem
child) at the moment, but hopefully someday someone will implement the
small piece of infrastructure we need.

License Harmony

The whole gcjx effort would probably not be needed at all if we
had better license harmony. Instead we would just share efforts with
some other free java compiler. This situation is pretty lame. I
suppose we could have worked around it by having a little driver that
runs a different compiler and feeds the resulting class files to gcj;
but that feels too much like intentional GPL circumvention for my

Of course, now that I’ve sunk a year’s worth of spare time hacking
into this, I find I don’t really want us to reach license

Nevertheless, I see this as one of two major issues facing free
software, with the other being patents. Patents are an external
threat, a way that companies intent on protecting their antiquated
business models can (with luck temporarily) defeat us.

Lack of license harmony is more of an internal threat, balkanizing
the community: putting up barriers to code sharing and communication,
and creating software stacks that ought to interoperate but cannot do
so efficiently.

The Control Room

An interesting documentary about the Al Jazeera network.
Trenchant yet, for my taste, a bit jumpy. The political observations
in it have circulated on the US left for quite a while, so it wasn’t
surprising, but nevertheless it managed to be moving. Squeamish as I
am, I had to close my eyes a couple of times. The personal
observations were quite well done, reminiscent in a small way of The
Sorrow and the Pity.

Double Success

Yesterday I got my first .s file from gcjx. This
means that enough gcc integration exists to avoid crashing, and that a
fair chunk of the tree lowering pass exists. I wrote a letter about
making a new gcc branch, now I just have to make myself actually send

Eclipse 3

Today I got Eclipse 3 to start up using the “BC branch”
interpreter. Now to try compiling bits of it.

First Link

Tonight I turned gcjx into a shared library and hacked on the tree
back end enough to make it link. You have to go through some build
hackery to make this work for yourself — I suggest waiting for the
gcc branch. That should be coming a lot sooner than I thought.

My goal is to get gcjx fully working (to 1.4) and in the gcc tree
by its one year anniversary, December 1. Today this looks completely
possible, given that it is already better than gcj in most

A little bit of everything

This week was fairly scattered, I ended up doing a little bit all
over. Work was mostly bug fixing, or in some cases just bashing up
against regressions all over. We never have quite enough testing or
quite enough time to look at little problems as they crop up. And of
course the test suite doesn’t include big things like Eclipse 3 that
stress many things at once.


I added a renaming feature to GDirect this week. Now it is pretty
easy to control the mapping of a Java method name to the underlying
native function name. There is an interface for renaming, and a
couple useful built-in renamers. So, for instance, now you can have a
Java-style method name like “setFocusOnClick” and have it call the C
function “gtk_button_set_focus_on_click”.

Currently I’m thinking of wrapping object-oriented C APIs (e.g.,
gtk) by having these classes derive from a Pointer class that supplies
the implicit “this”. There are several plausible approaches, but this
one is simple and fairly easy to understand.


I had taken a small hiatus from gcjx, but I’ve been working on it
more lately. Mostly I’m working on lowering to the GCC tree
representation. Really that is largely there and I’m really doing
some cleanup work and writing some of the needed glue — building all
the right decls, hooking in to gcc’s command line processing, stuff
like that. None of this stuff compiles.

I’m planning to relicense gcjx to the LGPL. This will let me do
things like use it from ant via dlopen(). I’ll have to rewrite a few
little bits that come from the old gcj. The tree-lowering code will
remain GPL, since it links directly into gcc.

Once I get it actually able to compile a java program to trees
without crashing, I think I’ll try to get it into the gcc repository
on a branch. Currently I’m thinking most of gcjx would go in a new
top-level directory (like libcpp), with just the tree-lowering and
glue code in the gcc directory.

Writing a GCC front end

Once you understand trees (there are some intro manuals
around, a couple nice examples
— hint: don’t read gcj or g++, and as a last resort tree.def),
you might be wondering how to hook your front end to GCC. This part
was intimidating me a bit; I was afraid I’d have to dig through gcj to
figure it out.

I started doing this, but a simpler way is to read langhooks.h.
This provides a decent, though imperfect, overview of what a front is
either required to do or can easily override. It doesn’t mention
things like build_common_tree_nodes, and I’m sure other
stuff I have yet to figure out, but it is still pretty helpful.