We do all of that in linux-threads. Somebody needs to debug it though
and I don't have the time.
- Godmar
>
> 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.
>
