[bitc-dev] memory management primitives

[Sam Mason]

On Tue, Dec 12, 2006 at 11:16:12AM -0500, Jonathan S. Shapiro wrote:
> 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. :-)

Noo problem.  When BitC starts to get used by you in anger I expect this
sort of thing will get cleared up pretty quickly.

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

Aren't the initialisers for these data structures going to have to live
in the data segment anyway?  Getting control (probably implicitly) over
this sort of thing could be good, especially for embedded people.  This
sort of thing quickly becomes an "implementation issue" though.

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

That still sounds as though it would be a useful thing.

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

It's more the assumption of a "dup" operator that was my problem.

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

I agree that knowledge of space banks is not the sort of thing you
want in a language, but allowing multiple heap allocators seems like
a requirement for a server process being able to allocate memory from
client supplied memory.  But then again I may be misunderstanding the
purpose of "dup".


  Sam