alanlb@access.rrinc.com wrote:
| I've spent the past few days investigating a case where the BeOS port,
| which employs native threads, fails to run to completion.  Specifically,
| the failure occurs with the "ClassGC" test in the regression suite, and
| does not happen with every run (ie, it is thread execution
| order-dependent).

This may not be entirely relevant, or it might.

For any port using native threads, the following must be considered:

1. When the GC thread does a GC, no other threads may run.  This is because
   if the GC thread gets preempted, then another thread may create a
   reference to an object by modifying memory that the GC has already walked.
   If the GC sees no other reference to this memory, then it will be freed,
   even though there is a reference to it.

   AmigaOS provides Forbid() and Permit() which nicely block other threads
   (as well as all other threads in the system, ugh).

   POSIX threads provides no adequate facility.

2. The GC thread must also walk the register files of sleeping threads, since
   in a JIT system, the only reference to an object might be in a register.
   This requires that the GC have some knowledge of how registers are stored
   on the native thread system (typically, registers are stored on the stack).

   Systems that do thread switching entirely in the kernel, and place the
   registers on the kernel stack, will not work out here, since the user-land
   GC has no way of reading kernel memory.

If these issues are not addressed, then subtle GC bugs may occur.

Note that if you are running your own thread package, tending to these is
easy, since you can provide the necessary functionality.