On Tue, 2006-12-12 at 15:40 +0000, Sam Mason wrote: > ...strings seemed to be > created on the heap rather than staying in the data segment.
This is a bug in the current low-level string representation. It's a low-level runtime issue. We know about it, but we're waiting on this until some other issues are resolved -- it's better not to dink with the runtime while you are dinking with the compiler. :-) > 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. For scalar constants this definitely should not be happening. For compound data structures, can you confirm that they are in fact value types? If they are reference types, they need to be heap allocated. Well, we could put them in the data segment, but then we could not GC them. > 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. Definitely possible. There is stuff in the preamble that gets heap allocated, which is one reason we need to look at the issue in a comprehensive way. > > > 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. Swaroop's description here is mildly misleading. I would say rather that we have considered a compile mode in which the compile will signal a compile-time error when it encounters a construct that allocates memory. > > > 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. It is certainly possible to implement type classes covering shallowCopy and deepCopy. The language doesn't need to support this directly. > Would naming space banks preclude having an arbitrary number of them? The BitC runtime has no knowledge of space banks, in the same way that the SML runtime has no knowledge of mmap() (that is: it is known to the runtime implementation, but not to the language specitication). shap -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC +1 443 927 1719 x5100 _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
