One of the things we talked about at the summit was what to about
Java programs in Fedora Core. People seemed pretty gung ho about work
in this area. Two concrete things to come out of this: we’d like to
get gcj-eclipse into FC4 (an unofficial “we”, hopefully RH will come
along), and, if we can get everything done in time, also gcjwebplugin.
The latter really seems like a stretch goal to me, there isn’t much
time and there is a lot of work to do.

gcjx

I’m ready to make the gcjx branch on gcc.gnu.org, but I’m
strangely reluctant. I think my hangup is that I still haven’t worked
out all the details of how to build the thing. I’d like to put the
bulk of the compiler in a new top-level directory, but I don’t see how
to make the bootstrapping work in this case. In particular, it seems
to me that if we build a native compiler, we’d like to use the
just-build libstdc++ for gcjx. But, that is hard because that is a
target library and is built long after the parts of gcjx that interact
with gcc.

I’ve had a full week and didn’t manage to find a minute to write
about the Free Java Summit, which was about a week ago. I thought it
was fairly successful.

There were a number of good talks. For me the most interesting
ones were about the Jupiter VM and about JikesRVM,
which is really an excellent program (check out MMTk, a GC-building
toolkit).

Miguel was there and he talked about Mono, and after the talks
spoke a bit about the Mono debugger and other things. We did talk
briefly about the possibility of a completely shared runtime — one
that could run both Java and .NET bytecode, without needing any of the
hacks that IKVM needs — but the
general consensus seemed to be that there isn’t a real use case for
it. That’s too bad, it sounds like a fun project 🙂

The very best thing, though, was that Onno Kluyt was there. He
chairs the JCP and urged us to join. Whether this will happen remains
unclear — we need yet another pass through the legalese — but the
current plan is to have someone (Dalibor 🙂 join and see about
running the TCK against kaffe.

BC Merge

I merged the BC branch to the trunk this last week. This turned
into a horrible disaster. My testing failed to catch some
bootstrap-breaking bugs, I failed to cvs add a couple of files, we
broke ARM newlib yet again (this port is the canary for the most
trivial target port bugs). I spent most of the weekend hanging my
head in shame.

gcjx

Elliott Hughes wrote a lot of nice code for gcjx this weekend,
including adding internationalization support to the output
formatter. He also has a knack for finding bugs.

My recent gcjx hacking has been on attributes. I think all the
parsing and semantic analysis of attributes is working ok. gcjx still
doesn’t read them from class files, or write them. And we don’t
actually use them in the compiler, e.g. @Override doesn’t
do anything yet. Still, this is a big step forward.

The missing 1.5 bits for gcjx are: some work on enums, and
implementing generic methods. The latter looks simpler than I had
feared.

There’s been some talk about arch and
other VC systems lately. I’m not really too interested in going over
all the details via a blog entry; we should probably set up a
version-control-flame-fest mailing list or panel at some conference
for that sort of thing. But, I did want to put in a few good words
for monotone.

monotone is very friendly for “off-line” use, by which I mean
there’s actually no such thing as “on-line” use as there is with cvs.
You keep the subset of history that you want in a local database, and
all the ordinary user commands interact with this. You can sync this
database with other databases; I would suggest ordinarily just doing
this automatically via cron. Ordinarily it is simplest to just keep
all of history around.

A consequence of this approach is that you can commit at any time.
If two commits are made against the same base revision, a micro-branch
is made that you must then merge. This has some nice properties. For
instance, if someone sends you a patch against some release of your
package, you can just check out that release — no matter how long ago
that was — apply the patch directly, and then use the normal monotone
merge commands to merge the results with other changes.

Since monotone has all the other nice properties of the current
generation of free VC systems (atomic commits, cheap branches), and
since there is no enforced central server, it is trivial to do things
like have experimental branches, private branches for unfinished
patches, and the like.

You can do one better than that, though. With monotone you aren’t
required to accept any particular person’s changes, you can choose
keys to trust and keys not to trust. The way this would work is that
core maintainers would be generally trusted (you could have a
re-signing robot to automate this if you cared). Other people could
commit patches more or less freely, they just wouldn’t show up until a
core maintainer approved them. So, this would be a nice supporting
piece for the typical project, where non-core maintainers submit
patches for approval; it would eliminate the need to actually apply
such patches.

The other feature worthy of note, and the reason for monotone’s
name, is its support for testing. Monotone lets you attach some
metadata to a revision (using the normal signing process); then you
can use this metadata to change how “update” works. So, you can have
an automated tester sign
revisions that are known to work, and then only update to
known-working versions. For GCC, you could have multiple such
testers, with different acceptance criteria (works on x86 native,
works for ppc cross, etc).

Some of my Eclipse wish-list items got crossed off this week:

• As Anthony writes, you can download the the ChangeLog
  plugin. This plugin makes it much easier to hack on GNU Classpath
  in Eclipse.
• There’s now a bugzilla
  plugin for Eclipse. It is still a work-in-progress but at least
  seems to let you integrate queries into your workspace.
• GCJ Builder lets
  you compile projects with gcj.

Lives up to its name. I loved it.

Dave
Orme’s blog on Eclipse and gcj came at a funny time. We’ve really
solidified parts of gcj recently, so compiling SWT and Eclipse is
basically trivial now. Also, I recently made a list of
projects that would help integrate Eclipse better into the free
software world. I’ve been meaning to propose this as a theme for the
next round of Eclipse development, but haven’t quite figured out who
to send it to.

This week I’ve been working on the new gcj binary compatibility
code some more. This is looking pretty solid now, so I thought I’d
write a little tutorial on compiling a random Java application. If
you want to do this, you will need to check out the BC branch and
build it. We’re planning to merge all this into the trunk in time for
GCC 4.0.

The general approach is to make a small database that maps class
files (by hash code) to the shared library defining the class. This
approach doesn’t give the best possible performance, but it has the
advantage of working transparently with any application. If you’re
willing to modify your application a little (or if your application
just uses the standard class loaders like
URLClassLoader), then you can do a little better.

The branch has Andrew’s new jv-dbtool program
(probably will be renamed) which is used to manipulate the database.
First run it to create your database:

mkdir /libdir
jv-dbtool -n /libdir/eclipse.db

Now, compile each jar file using the new verifier (eventually this
will be the default) and the indirect dispatch code:

gcj -fnew-verifier -findirect-dispatch -fjni -fPIC -shared -o /libdir/foo.jar.so foo.jar

Update the database to know about the new jar:

jv-dbtool -a /libdir/eclipse.db foo.jar /libdir/foo.jar.so

Now you’re ready to launch your application. Run it using
gij, and arrange to set the system property
gnu.gcj.precompiled.db to point to your database (you
can use a number of databases separated by “:” if you like):

gij -Dgnu.gcj.precompiled.db=/libdir/eclipse.db My.Application.Class

That’s all there is to it! Your application will use the compiled
classes. You can debug your application with gdb, profile it with
oprofile, etc.

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.

gcjx

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.

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
a
pointer. This came at the right time since rewriting the class
reading code was the last thing to do before I could relicense gcjx to
LGPL.

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.

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
implementation.

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 :-).