On Tue, Dec 05, 2006 at 04:30:10PM -0500, Swaroop Sridhar wrote: > 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.
Those all sound reasonable and I'm not sure how they would be done any other way. I haven't use the compiler for a bit as there doesn't seem to have been many changes going in recently, but strings seemed to be created on the heap rather than staying in the data segment. Also a lot of the constants that I created seemed to be put on the heap as well. Not sure if it's just my memory though. I've just written a simple helloworld program and it seems to contain 21 references to GC_ALLOC. This is a very bad metric but it's where I got the impression of lots of heap allocation from. I know that the compiler is very on in it's life so I fully expect it to be generating lots of unnecessary code and what I said before wasn't meant as a complaint. > > 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. Sounds good. > > 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. My original thought is that the typeclass would be like a copy-constructor in C++, it would be up to the library implementing the memory allocator to call the appropriate constructor. I quickly realised that would mean exposing references to things where they shouldn't be exposed. It would also be possible to forget the initialisation, which would be bad as well. Would naming space banks preclude having an arbitrary number of them? My naive interpretation of naming suggests this, but I don't know what you're thinking about them. > > 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). One thing that springs to mind is that in Cyclone references may only be stored in regions with an equal or a longer life. For example you wouldn't want to store data associated with client1 in client2's region, but you may want to store it (temporally) in the processes own region. This may be the sort of thing you want to prove through other methods though. > > 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. That makes sense, but you're getting into uncharted territory quite quickly that way (I think). I've been reading about alias types recently and they sound as they could allow some very clever things to be checked with respect to the safety of code but their properties sound even less well known. Sam _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
