[bitc-dev] memory management primitives
sam at samason.me.uk
Mon Dec 4 13:05:19 CST 2006
On Sun, Dec 03, 2006 at 02:56:11AM +0100, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 02/12/2006 hora 12:34:
> > I'm not convinced that the language should provide support for
> > threading or co-routines.
> I thought that because of possibly bad interactions between GC and
> threads, it would be needed for a GCed language to provide threading
> support (instead of being able to use any external thread support, like
> you could in C/C++).
I think I remember Shap saying that the kernel will be written in BitC
and for various reasons the kernel can't have (and in practise probably
doesn't want) a general garbage collector---additionally the hardware
will also impose it's own threading model. This suggests that there
will be a core of BitC that will be usable without garbage collection.
The current BitC generator is very happy to put everything on the heap,
but I'd be interested to know how long this behaviour is expected to
Also interesting is the "dup" procedure. This explicitly returns a
heap allocated (shallow?) copy of its parameter. I thought that EROS
processes can have several space banks (not sure if this is right term,
but the intention is that there are several places that memory can come
from depending on who you want to be held accountable for it), if so
which one is chosen to be used when you "dup" a value.
The C language is notable in its absence of a general purpose allocator
and I'm wondering if BitC should follow suit; maybe leaving "dup"
like functionality to some clever use of type classes (which can be
automatically generated by the compiler like the Eq and Show classes are
for data types in Haskell) and library code.
Or is all this in the spec already and I'm just being stupid!
Back to Pierre's question; why can't you just bundle the threading and
GC into a single library. The problem with this is that once it becomes
possible to replace the GC/threading model then different libraries will
want different implementations and getting them to work in the same
bit of code becomes problematic. I think I remember that EROS tended
to put what would have been a library under Unix into its own process.
This would solve the problem and also have the advantage of allowing
appropriate selection of threading models/memory management.
More information about the bitc-dev