Re: Fwd: Re: Fwd: Re: Frame size for local calls

> From: 	Rob MacLachlan <[email protected]>
...
> Yes, it does mean that.   And it does waste some space, but not time,
> since it takes the same amount of time to allocate any amount of
> (uninitialized) storage.

OTOH more space sooner or later also means touching more cache lines,
using more memory bandwidth, and more space for the GC to scan.

> Unless you have a huge non-tail recursion,
> stack usage is likely to be in the 10's of kbytes range, which was not a
> big concern for me, even on a machine with 4 meg of memory. 

OK, then it's not a problem.  It just looked a little odd.

> You could
> avoid this by generalizing the register allocator to know about frames,
> or by doing local call in some other way.  Also, the register allocator
> deliberately wastes stack space by allocating stack storage in larger
> chunks, under the theory that this will make it more likely that the
> source and destination of a move can be packed in the same location,
> eliminating a memory-to-memory move.
>
> I think that what has proven to be the biggest adverse consequence of
> this stack wastage is that it makes dead pointers appear to still be in
> use because they were referenced by some stack slot that was allocated,
> but is never used by that function.    Of course, this could happen even
> if all of the stack slots were potentially used somewhere inside the
> function, since they still might not happen to be live at the time of
> the call.

Stack maps to describe the live slots at call sites would probably help
with that; at the price of considerable space usage (wastage?) for the
stack maps.

Helmut

_______________________________________________
cmucl-imp mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-imp