[Openmcl-devel] llvm backend
Jason E. Aten
j.e.aten at gmail.com
Tue Mar 29 13:40:35 UTC 2011
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
Quoting from http://vmkit.llvm.org/publications/vmkit.html summarizes the
"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
"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...
More information about the Openmcl-devel