[bitc-dev] memory management primitives
swaroop at cs.jhu.edu
Tue Dec 5 15:30:10 CST 2006
Sam Mason wrote:
> 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
> 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
The BitC implementation does not put everything into the heap. Only
dup-ed objects (including implicitly duped values due to closure
construction) and constructed values of with :ref structures/union type
live in the heap. All activations are built on the stack.
> This suggests that there
> will be a core of BitC that will be usable without garbage collection.
There have been considerations for allowing certain modules to be
"dup-less." That is, they can have statically allocated global values,
but cannot call `dup', construct values of :ref type, or have a
reachable function that closes over local state.
> Also interesting is the "dup" procedure. This explicitly returns a
> heap allocated (shallow?) copy of its parameter.
> 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.
Type classes may not be the right thing to use here. I think this only
works if all the space banks can be statically named.
> 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.
One possibility may be to admit a space-bank like feature into the
language, where we create different heap regions, and allocate memory
from them. The collector can also return memory to the appropriate
region. I think this is similar in spirit to Cyclone's dynamic regions.
The allocation of heap regions must, of course, be a controlled
operation in the kernel context (limited to certain modules).
> Not sure if it's quite as easy as I thought before; the main reason for
> having a "dup" operator seems, to me, to stop references escaping from
> locations whose type changes unexpectedly (the stack and unions spring
> to mind). How you could arrange type classes without exposing locations
> seems difficult.
Actually, tracking which memory (reference) belongs to which region can
be done using dependent types (region types), but as far as I know, the
accounting of storage, etc needs more functionality from the runtime.
More information about the bitc-dev