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. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
