Re: Done with Gcj?

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Matt Welsh wrote:

> Back to my original point, though -- I have not used GCJ for some time
> because I ran into many problems trying to run anything more complex than
> toy applications on top. It's not as though I gave up at the first sign
> of trouble -- I spent nearly 6 months banging on it, chasing down bugs,
> and digging into all aspects of both the compiler and runtime.
>
> Many of my problems stemmed from wanting to use more advanced features
> (such as dynamic class loading) which were unsupported by the older snapshots.

> Multithreaded applications gave me a lot of trouble, too - causing mysterious
> crashes which I could not attribute to my own code.

This surprises me, as I have a lot of confidence that our thread code is now very
good. It was fairly broken up until April or so. Please make sure to use glibc
2.1.3.  It is likely, I think, the problems you saw were either unrelated to
threading or possibly due to insufficient synchronization/thread safety in the
class libraries. In any case, if you have any test case (isolated or otherwise)
where I can reproduce a failure than I'd be very interested to see it and will
make efforts to fix.

I have observed an intermittent problem with the garbage collector on an SMP
system, but only in a pedantic test case and in this case a gdb session should
make it pretty clear that the crash occurs inside boehm-gc. Other than this I
know of no java threads test which fails to run perfectly on libgcj w/glibc
2.1.3.


>  Why is GCJ still relying upon separate patches
> (from folks like Bryce) to keep the new runtime working with the old
> compilers? It's really a mess.

Because we are dependent on gcc's release schedule. When gcc 3.0 is released,
we'll finally have a fast, stable, and featureful compiler. libgcj will be
integrated into the gcc tree, distribution vendors will distribute libgcj
out-of-the-box, and all of our version mismatch/compatibility problems will
vanish. Unfortunately, AFAIK there is still no time frame for the gcc 3.0
release.

Regarding old compilers - trying to maintain backwards compatibility while adding
new features as well as keeping up with general changes in gcc is a PITA (I
know). Perhaps for gcc 3.0 we should make more effort to maintain a
stable/compatible branch of libgcj. This way end users could drop in a new
library for bug fixes etc, without also having to upgrade the compiler.

> to make progress with gcj. If people are having better success with the
> system lately, I'd love to hear about it, and may consider going back and
> trying again. From what I can tell listening to the mailing list and looking
> at the web pages, it doesn't look like gcj is any closer to a stable,
> full-featured release than it was a few months ago.

Progress is being made, we've come a long way. However, help is of course
appreciated. There are unfortunately only a few of us contributing to gcj a
regular basis. As it improves and becomes more accessible, I think that more
people will use it and be willing to help out with development.

For now, I personally hope that Cygnus' will see fit to realize their investment
and allocate more resources to development and maintenance of the compiler, in
particular. Once the compiler has reached some level of stability (which I would
define as being able to correctly compile most of the code that's out there) then
I think acceptance of the GCJ platform as a whole will be greatly increased, and
subsequently new features will naturally progress much more quickly.

regards

  [ bryce ]