Related articles |
---|
Incrementally implementing a simple ML compiler using LLVM usenet@jdh30.plus.com (Jon Harrop) (2007-11-26) |
Re: Incrementally implementing a simple ML compiler using LLVM torbenm@app-2.diku.dk (2007-11-27) |
Re: Incrementally implementing a simple ML compiler using LLVM gneuner2@comcast.net (George Neuner) (2007-11-28) |
Re: Incrementally implementing a simple ML compiler using LLVM pertti.kellomaki@tut.fi (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=) (2007-11-29) |
Re: Incrementally implementing a simple ML compiler using LLVM jo@durchholz.org (Joachim Durchholz) (2007-11-29) |
Re: Incrementally implementing a simple ML compiler using LLVM usenet@jdh30.plus.com (Jon Harrop) (2007-11-30) |
From: | Joachim Durchholz <jo@durchholz.org> |
Newsgroups: | comp.compilers |
Date: | Thu, 29 Nov 2007 11:02:35 +0100 |
Organization: | 1&1 Internet AG |
References: | 07-11-072 |
Keywords: | GC |
Posted-Date: | 29 Nov 2007 23:59:06 EST |
Jon Harrop schrieb:
> Is the Cheney semi-space GC a suitable starting point? Is there an
> abstract interface for using a GC from generated code that I could
> adhere to?
>
> Is there anything else that I should be aware of?
Let me comlement the already-given advice by remarking that
implementing an efficient, robust GC is D**n Bl**dy Hard (TM). Entire
lifetimes have been devoted to writing and tuning a GC.
That's the reason why most people stick with the Boehm/Demers/Weiser
collector. This will give you a reasonable GC, allow you to
concentrate on other issues, and come back to the GC side of your
system when you have the time.
The risk with that strategy is that the Boehm collector will warp the
design of your run-time. OTOH unless you're already a GC guru, your
run-time design will likely warp the GC design into something less
efficient than it could be, so there's no risk-free strategy anyway...
Regards,
Jo
Return to the
comp.compilers page.
Search the
comp.compilers archives again.