[Openmcl-devel] llvm backend

[Jason E. Aten]

On Mon, Mar 28, 2011 at 6:25 PM, Gary Byers <gb at clozure.com> wrote:
>
>  If the situation's changed or if I'm portraying it incorrectly, please let
> me know.
>
> If I'm correct about that, I personally think that precise GC in the
> presence of native threads is too important to seriously consider the
> idea of using an LLVM-based backend (and I have other concerns about that
> as well.)


The one concrete example I could find of using LLVM with native threads and
garbage collection is the VMKit implementation of a JVM and CLI. Geoffray et
al used the MMTk memory management toolkit for this, which originally
implemented multithreaded GC for the JikesRVM.  Interestingly, the MMTk is
apparently written in Java, so they had to bootstrap with a primitive no-op
GC, compile the MMTk into LLVM IR using their Java->LLVM IR compiler, and
then they could actually compile MMTk to native code/incorporate it into
their new JVM and use it for their CLI.

But I think the most important thing to note is that it looks quite slow,
since any GC appears to require all threads to sync up.  And they aren't
able to utilize registers effectively, it appears, due to design constraints
of LLVM.

Quoting from http://vmkit.llvm.org/publications/vmkit.html summarizes the
situation:

"To address the constraints of efficient multi-threaded garbage

collection, we associate each thread with thread-local storage implemented

in the first few pages of the thread’s execution stack.

Because each stack is aligned on a power of 2 boundary, finding

a pointer to the local storage of a thread requires only masking

the thread’s stack pointer with the boundary complemented by two.

This approach gives access to the thread local storage without performing

a function call, as would be required with POSIX. Alternatively,

we could have reserved a register to hold a pointer to the

thread-local storage, but this approach would have required modifications

to LLVM.


"As shown in Figure 1, a high-level MRE must provide to the

thread manager a function for finding the root objects in the execution

stack of each thread. When a garbage collection is triggered, all

threads must join a handshake, so that the garbage collector knows

the objects referenced on the stacks. To implement a handshake,

a thread-local boolean variable is regularly polled by the threads

(on return calls and backward branches) to verify if a collection is

happening. Once all threads have joined the handshake, the thread

manager invokes the function provided by the high-level MRE to

find the root objects in the threads’ execution stacks."

Assuming CCL does not require thread synchronization in order to collect
garbage (correct me if I'm wrong) I would expect CCL to beat the pants off
the above strategy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20110329/1efce6ca/attachment.htm>