[m-dev.] Attn Peter Wang: CTGC idea.

[Paul Bone]

On Thu, Aug 21, 2008 at 05:26:21PM +1000, Peter Wang wrote:
> On 2008-08-21, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > 
> > Attention Peter Wang.
> > 
> > I don't know if you've considered this as part of your CTGC work or not
> > yet.  alloca (C function) provides very cheap memory allocation and
> > deallocation using the program stack.  Even though we don't use the C
> > program stack in LLDS backends I'm sure we can write something
> > equivalent.
> > 
> > Java promotes some heap variables to stack variables using a technique
> > like this when it's analysis shows a variable being created and
> > destroyed when the same stack frame is at the top of the stack.  Perhaps
> > we could do a similar analysis and use this technique too?
> 
> Yes, I suppose we could.  So if you construct a cell and it dies by the
> end of the procedure, and remains unique, then you don't have to
> allocate it on the heap.  We can't use the detstack.  The C stack might
> work, but I'm not sure how portable that would be.  On the high-level C
> grade we could use a local variable.

ah a local variable should be fine in the hlc backend,  I forgot that
alloca is only useful when you don't know the size of the allocation at
the time of writing the code.

Why can't we use the detstack?  surely we can use it when executing code
with at most one solution? or is this because we can't allocate
multiple-word objects on the detstack?

I don't think we can use the C stack at all in low level C grades.
Since we jump over the beginning and ends of functions where the C stack
is manipulated, the memory would never be collected.

> 
> Of course then there's rbmm.

Last time I tried to understand this I didn't get very far.  I don't
expect I have the capacity to understand it know (I'm already overloaded
with so many other informations).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20080821/e70b520a/attachment.sig>