Archive for the ‘Uncategorized’ Category

FOSDEM 2006

I’ve been back from FOSDEM for a couple of weeks. I had a rough
homecoming, though, and after that got lost in catch-up and bug fixing
for a while. Now I’m finally ready to write about what I saw.

The Classpath contingent was lively again this year — some new
faces, but also, unfortunately, some folks didn’t make it. I suppose
we’ll never achieve 100% attendance; that’s ok since I always leave
FOSDEM feeling as though I should have somehow fit in even more
talking than I did.

I stuck to the Classpath room this year. I had really wanted to
get over to see the PiTiVi talk in the Gnome
room, but this overlapped with the Classpath general discussion
session and so I couldn’t leave. Maybe with FC5 I’ll be able to
easily build my own pitivi and demo it to myself.

Free Swing – Roman Kennke

The first talk I have notes for was the Free Swing talk by Roman
Kennke. He gave an overview of the Swing work, contrasting November
2004 (when he started working on it) with today. The Swing hackers
have made huge progress — a year ago it couldn’t really do anything,
and now it can run many actual programs. There are still some
missing things, but today the list looks doable.

For 2006 Roman essentially predicted completeness. His real list
was styled text and HTML, 1.4 compatibility, stability, usability, and
java2d.

CORBA – Audrius Meskauskas

Audrius talked about his work on the GNU Classpath CORBA
implementation. He may have mentioned his work on RMI in passing —
it isn’t in my notes but I remember something about this.

Audrius singlehandedly wrote our CORBA code. Some of the other
free ORBs rely on un-free code — IDL from the OMG which can’t be
modified (incidentally this is apparently one reason we avoided
jacorb). Not us, Audrius reverse engineered it from the spec. Our
implementation also passes more of the official test suite than other
implementations.

JamVM – Robert Lougher

The first thing my notes say is, “send him some congratulations”.
So, congratulations, Rob. JamVM is an excellent program. I use it
every time I work on Classpath and I’m always grateful that it is so
easy to set up and use.

Normally I’d follow this with a wish-list, but as Andrew pointed
out, the time lag between “that’s cool” and “feature X is broken” is
often much too short. So let’s just leave it at congratulations
🙂

Rob’s talk mostly concentrated on JamVM’s implementation approach.
It is what I would describe as a state of the art interpreter. It is
direct threaded, it does stack caching (it has 2 cache registers and
hence 3 versions of each opcode — except on x86 where this is not
very useful), and does dispatch prefetching.

Apparently the stack cache yielded a 20-50% improvement, depending
on the benchmark, especially in combination with the dispatch
prefetching (also called interpreter pipelining or something like
that).

Vmgen – Christian Thalinger, aka twisti

Twisti gave a talk on incorporating a vmgen-based interpreter
into Cacao. vmgen is a cool project from Anton Ertl (read his
interpreter papers, they are quite nice) which automates certain
aspects of stack-based interpreter construction. The basic idea is
that you write your instructions (in a kind of mixture of C and a
forth-like language) and it will generate your interpreter.

The trick is that vmgen knows how to do all the nice interpreter
optimizations for you, so you don’t have to do them by hand. So, it
can do direct threading, stack caching, dispatch prefetching (Twisti
said it doesn’t have this, but I know I first read about it in one of
Ertl’s papers… so I dunno), and both static and dynamic
superinstructions.

A static superinstruction basically turns a common static
instruction sequence into a single instruction. You decide what
superinstructions to make, and then the code that vmgen generates to
handle direct threading will automatically recognize these patterns.
The idea is to cut down on dispatch overhead for common code.

Twisti said that they tried the absurd approach of having 10,000
different superinstructions, but in the end found that just having 100
is enough.

Vmgen also can do dynamic superinstructions. The idea here is
similar to that of SableJIT (or qemu, I think, though I haven’t
looked), where you memcpy the executable instruction
sequences (that GCC generates for your hand-coded VM instructions)
into a big buffer, and then execute that. It is basically a cheap
JIT.

Now we just need to get Ertl to hook vmgen up to LLVM 🙂

Twisti thought it would take about 2 weeks to get a vmgen-based
interpreter up in another free VM. I’d imagine that due to oddities
in our ABI it might be harder to do it for gcj :-(.

Both Rob and Twisti had performance results. Both these
interpreters beat gij pretty handily (and also the Sun and IBM
interpreters), probably due to our ridiculous function call overhead.
I forget which of vmgen or jamvm was fastest; I think they were
reasonably close.

Knopflerfish OSGi – Philippe Laporte

Philippe Laporte gave an impromptu talk about Knopflerfish OSGi.
I didn’t take many notes on this, except that it is BSD licensed right
now.

My Talk

I didn’t take any notes on my own talk. That would have been
weird. My talk was about hacking on Classpath in Eclipse. This went
pretty well — I used the native eclipse on my laptop and didn’t have
any major problems. The talk is basically already encapsulated in a
page
on the Classpath wiki
.

Round Table

At the end we went around the room to talk about what we were
doing and the like, led by Mark. I learned some interesting things
here.

Robert Schuster got a job hacking on Classpath, and in particular
Swing. His company does some kind of office application.

Wolfgang Baer talked about printing a bit. He talked about using
iText for printing PDFs.
I didn’t really understand what he was about until I saw his patch
this week that implements an IPP client in Java. I’m constantly
amazed at what Classpath hackers come up with — congratulations
Wolfgang.

Our Plans

I also talked a bit about what we’re doing at Red Hat. Nothing
here is too surprising. We’re currently working in several areas:
JDWP (so you can debug from inside Eclipse), security, the library (in
particular Swing and java2d), and 1.5 stuff (compiler, runtime, and
library).

We tend to do application-driven development, where we look at
the applications that we want to have working, and then finish the
things needed for those.

We’ve got a pretty long list of interesting applications at this
point: jonas (which is driving some of our performance work), the RHDB
tools, Fedora Directory Server (this drove some of the Swing work),
Megamek (found lots of AWT bugs), FOP/Batik (driving Graphics2D work),
gcjwebplugin/netx (driving security work). Of these I would say that
gcjwebplugin is probably the most interesting.

Everybody got a chance to speak during this part, but I didn’t
write down most of it. There was a film crew here, too, and at the
end they asked some questions, which were ok but a bit on the bland
side.

FOSDEM

I’m leaving soon for FOSDEM
and getting all my stuff in order. (Unfortunately due to my lame
setup I won’t be writing any blog entries while I’m away… I really
need to fix this. I’ve been eyeing bluehost, since that is what Elyn
uses.)

At FOSDEM I’ll be giving a demo on using Eclipse to develop
Classpath. Not super deep, but something I’m passionate about. This
switch gave me a a major productivity boost, and I think this is
something that most Classpath developers can benefit from.

In fact this boost is one reason I’m interested in changing g++ to
be better — moving from the Java world back to the C/C++ world is
amazingly painful, and not for any good reason. One way that GCC’s
relative dominance is a bad thing in that there’s no competition to
force it to improve quickly. That is, there is competition on the
back end from things like icc, but nobody is carrying the flag for
developer productivity and front end improvements.

Medi8

I’ve done a little Medi8 hacking lately. I have thumbnails
working better and it can now turn its internal model into Westley
XML
. This means we’re a big step closer to, you know, actually
doing useful things like playing or exporting the resulting
movie.

Miscellaneous Stuff

libjit
looks pretty nice; pity Mono didn’t take this route. I’m not sure
why you’d use this rather than LLVM though.

I’ve been using mock lately.
This is a nice tool that makes it easy to build an SRPM in a
particular environment. I’m trying to set up an auto-builder which
will build gcj from svn, then use the result to build all the
java-based RPMs in Fedora. The idea here is, continuous testing as
close to upstream as possible will let us avoid ugly regressions late
in the release cycle.

Aspect-Oriented C++.
Madness! But, I suppose, one more reason that one might want an API
to the compiler’s internals.

I didn’t realize this before, but Chandler also has a copy of
libgcj in it. I suppose this is for PyLucene… funny. Their plan
for integrating
into distros
mentions using the system libraries, python, etc… I
wonder if they know about the BC ABI.

I’ve been interested in Deming’s 14
points
lately. I’m particularly interested in number 8, “drive
out fear”, since it has a personal application, but really all of them
are worth a read and a think.

gcjx non-status

This week I proposed
killing gcjx
and replacing it with the Eclipse compiler.
Per had looked into this before, but this proposal was triggered by a
comment that Andrew made on irc that same morning. I surprised
myself by taking to it with enthusiasm.

Since then I’ve done some more investigation. This project seems
very practical, and I think will let us have a 1.5 gcj much quicker.
There are a couple potential optimization regressions by going this
route, but these are fixable in the compiler without too much work.

I also spent a little time hacking on the eclipse compiler’s
driver, trying to get it in shape for an experiment to test this
plan. That turned out to be easy.

While doing this though I finally felt the sadness I knew would
eventually arrive. The trigger was something very minor — I was
looking at the eclipse compiler driver, and realized that on a lexical
level it is pretty ugly code. There aren’t many comments, and the
ones that are there aren’t very good; the class I was hacking on
didn’t have a very layout or even consistent indentation style. And
so I took a quick look at the corresponding code in gcjx… we’re
definitely losing something in this exchange. (But to be fair, the
driver is not exactly a core part of the compiler. I doubt it gets
much love.)

We’re not losing much though, and I still think this is the best
way forward. Plus, and this also surprised me, I seem to have gotten
whatever emotional fix I was looking for from writing gcjx. I started
it at a kind of professional local minima, and writing it helped
remind me that I’m reasonably competent at this programming thing.
Now I’m on to feeling inadequate at a higher level.

Future compilers

I think some aspects of gcjx should be emulated in all future GCC
front ends. For one thing, front ends should have their own
representation, derived from the language being compiled — they
should treat GCC trees as a target format, not a high-level
representation. Trees aren’t statically typed, and they carry too
much other baggage as well.

Second, front ends ought to be written as libraries. These days
it isn’t enough to write a traditional batch compiler — you really
want to look ahead a bit and consider IDE indexing, incremental
compilation, and other uses of the parser and semantic analyzer.

More recently I’ve been interested in applying this treatment to
the C++ compiler. Recently I’ve been surprising myself quite a bit; I
was never interested in C++ compilation at all until the last few
months.

Frysk

I was looking around today and noticed that Frysk has a redesigned web page.
Looking good!

The “questions” page seems to be fleshed out a bit more, at least
as compared to what I remember. For one thing it is a lot clearer
about the relative strengths of frysk and gdb. Nice job guys.

Context-threading

Graydon pointed me at a
paper on context threading
, a somewhat different way to organize
an interpreter. It is a nice trick — subroutine threading with a
twist, or a baby step toward JITting. It is a way to avoid trashing
the pipeline, which happens in an ordinary interpreter due to all the
unpredictable branching. Unfortunately I don’t think this would work
well for gij, due to the way we handle exceptions; a problem that also
affects most of the JITs we’ve considered embedding. Andrew has
talked occasionally of changing our exception handling approach, that
is looking more and more necessary.

Java Language Future

Here’s the
presentation on the future of the Java Language
that I saw part of
while I was in Brazil. It is interesting for the most part. The XML
bits are fairly weird.

Trying Chandler

I downloaded and installed Chandler yesterday, and
copied over my (few) appointments to try it out. I only use evolution
for its calendar, and I’ve left it running as well so that I can more
easily compare the two side-by-side.

Chandler installed easily — the FC2 RPM installed without hitch
on my FC4 box. There’s no
.desktop file
for it, so I ended up making one of my own… in
general its Gnome desktop integration is weak at the moment. The
install is big, but then they do package their own copy of Python in
there — a typical (and sane) ISV approach, but still a little
unfortunate.

Chandler is definitely prettier than evolution. It shows my
events in color with a nice (but by now almost standard) gradient
effect. The icon for Chandler is also beautiful, though again in a
somewhat standard way. You can see this stuff on the main Chandler
page.

Chandler does fix one evolution bug
that has bothered me
. So far they are doing well on the little
details like these, especially when you consider that this is a pre-1.0
release. Also, they have been very responsive on my bug reports —
big plus to them!

It seems more memory-hungry than Evolution, that’s a minus.

I didn’t try any of the sharing stuff. Unfortunately for Chandler
my calendaring needs are quite modest at the moment.

I frequently wonder about the rationale behind writing Chandler.
It is nicer than Evolution in some ways, but surely not enough to
justify writing an entirely new application. Is it really about the
cross-platform-ness of it? As in, success looks like Mozilla, having
users across the platform spectrum? I haven’t found a really straight
answer to this, and I missed a chance to ask it directly at
OSCON.

Cosmo

The OSAF is also working on Cosmo,
a calendar server. This is an area I’ve never really looked into; I
seem to remember hearing a lot of complaints about the lack of this in
the past, but now there seem to be a few of these around. Maybe
someone out there knows what they are and how to compare them?

Netx RPM

I’ve packaged Netx for FC5: x86
RPM
, SRPM.
Thanks to Anthony this version will install itself as the handler for
JNLP files. WARNING: I’ve disabled the security code in this version,
so use at your own risk.

Install it and you will have a new javaws command.
Now you can try a couple fun things. First, listen to the radio:

javaws -headless -jnlp http://irate.sourceforge.net/webstart/stable/irate-client-swt.jnlp

(This one must be run headless due to an unusual
bug
… either be patient while it downloads, or run it normally
and then kill it after the download and then re-run with
-headless.)

Then you can run a fun game:

javaws -jnlp http://rockz.co.uk/preview/plugin/rockz.jnlp

I’ve been playing this lately but I’m really bad at it.

Unfortunately netx doesn’t play too well with gcj 4.0.x, so this
package won’t really work on your FC4 box.

Duh, I just realized that I should just give out real JNLP links:
here’s iRate
Radio
and Rockz. I
still haven’t tried this part, let me know if it works 🙂

Rockz

I went through a number of the applications on the connect and work
site
, trying them with netx and gij. Only a few really worked,
mostly due to bugs in our still-new swing implementation.

However, Rockz is a fun game
that actually works great.

Last night I made a netx RPM; I’ll post it once I dig up a rawhide
box to test it on.

NetBeans -vs- gcj

The NetBeans FAQ mentions
gcj
. We must have officially arrived. Dalibor thinks we’ll run
NetBeans this year. I’m a bit less sure, simply because it uses a
number of internal APIs, which are occasionally a pain to work
around.