Status page

[Loren James Rittle]

In article <75A9FEBA25015040A761C1F74975667DA13693@hplex4.hpl.hp.com> you write:
> It looks like gcj is built with thread support, but the gc is built without.
>
> I forgot about this particular failure mode.  Basically it's crashing
> because the allocator finds itself running on a different stack from the
> one it's expecting.  It's not surprising that that would happen in this
> configuration.
>
> This build looks extremely unhealthy, in spite of the mixed test
> results.  The tests pass only because they're mostly single-threaded and
> don't garbage-collect.

Having done a port, I'd like to add some practice guidance.  To people
that want to improve libjava with thread support on Darwin or another port:

A correct technique is to get `make check' working well in boehm-gc.
[Aside, I found many bugs in the pthread implementation on FreeBSD 4.
They were not all addressed in the OS/libc_r until FreeBSD 4.7.  I
know Darwin shares libc with FreeBSD if we go back far enough but I
think you guys have a completely different pthread implementation
so you will at least have a different set of issues to work through.]

For example, here is sample correct output for i386-unknown-freebsd4.7:

$ gmake -sk -C i386-unknown-freebsd4.7/boehm-gc check
Making check in include
Completed 3 tests
Allocated 5694401 collectable objects
Allocated 306 uncollectable objects
Allocated 3750000 atomic objects
Allocated 33000 stubborn objects
Finalized 6603/6603 objects - finalization is probably ok
Total number of bytes allocated is 186692524
Final heap size is 9854976 bytes
Collector appears to work
Completed 157 collections
PASS: gctest
==================
All 1 tests passed
==================

If that test doesn't run reliably and report `Completed 3 tests' as
the first line of output, then it is doubtful that libjava built against
that copy of boehm-gc could work reliably with threads on your port.

If it reports: `Completed 1 tests' but you thought libjava itself was
building to support threads for your port, then you have the
unhealthy, unchecked situation described by Hans.  In this case, you
will need to update the configuration of boehm-gc for your port (you
might look at ChangeLog entries to change a port configuration from
only single-threaded support to also multi-threaded support).  If your
port supports all the nooks and crannies of POSIX threads, then it
might be a simple matter.  However, have a system debugger that
understands threads ready to go. ;-)

If it crashes in any way or reports anything other than a completion
message, then debug it alone using the techniques described in the
boehm-gc sources *before* attempting to improve/debug libjava thread
support for your port.  Also, you will probably find debugging the
single-threaded boehm-gc configuration for your port to be easier than
debugging the multi-threaded boehm-gc configuration.  I.e. make sure
you can build a single-threaded configuration that runs the test
reliably before attempting to setup and debug the multi-threaded
configuration.

Regards,
Loren