[racket] [gambit-list] Gambit roadmap
On Tue, Jul 19, 2011 at 08:54:12PM -0400, Marc Feeley wrote:
>
> On 2011-07-19, at 5:29 PM, Hendrik Boom wrote:
>
> > The world has long needed a good, practical, flexible GC that can handle
> > parallelism. The days that each programming language had to have its
> > owm specialized and incompatible GC should be numbered. But running the
> > GC in parallel with the program it's collecting is costly without
> > hardware support.
>
> I'm not sure what you mean. Which hardware support? You mean special assembly instructions? That's doable in C with #ifdefs and inline "asm".
There has to be coordination between the garbage-collector's accesses to
memory and the program's modification of hte same memory. That involves
significant overhead unless you can handle really fast the common cases
where nothing much is going on very fast. I suspect that means
manipulation of virtual memory or a variety of exotic indivisible
instructons, but I haven't really looked at the details lately.
But I think that synchronising with the garbage collector is going to
involve a significant performance hit, which might be offset by having
lots of processors.
-- hendrik
>
> >
> > The C-- project has some ideas how to manage the interface between a GC
> > and its language. They may be right on how to do it, but I don't think
> > their interfacing has yet been tested on anything parallel.
>
> I followed the C-- project way back when it started, and the last time
> I checked (2006) it hadn't lived up to all the hype. The project
> seems pretty dead at this point.
I think it's been implemented on a few different processors now. And
the language is a clear and elegant design. What it lacks is a lot of
inplementation. That said, the design looks good. And none of the
implementatinos do JIT compilation.
Well, the Hasell people say they've taken the basic abstract machine
design and adapted and used it internally, using different data
structures than files of lines of text. Of course, they've abandoned
the notation, and their implementation is completely imdependent of
the mainstream ones, so perhaps it was more a design motivation than
anything else. Still, it may be worth looking at what they're doing.
If it doesn't turn out that seeing what they've done is more work than
doing it yourself. It does sometimes end up thhat way, doesn't it.
I don't know how C-- can implement C, though, with its vararg arguments.
-- hendrik