[bitc-dev] memory management primitives

[Swaroop Sridhar]

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
> survive.

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.


Swaroop.