TempAlloc

[dsimca]

== Quote from Fawzi Mohamed (fmohamed at mac.com)'s article
> I think that it could be useful to add an argument to to
> frameInit/free, in any case not just to speed things up, but to quickly
> catch mismatched init/free calls.

Can you elaborate on this?  I'm not exactly sure what such an argument would look
like.  Also, I wanted to make TempAlloc fairly simple even if it costs some
performance so that I would actually want to use it.  If doing something like this
adds a lot of complexity for the caller, I probably won't implement it.  Right
now, I like the simple mixin API.

> using GC.malloc in malloc for large requested sizes kind of defeats the
> stated purpose (and what makes superstack more difficult to use) of not
> being GC scanned, even if I understand the problem of either making
> bookkeeping more complicated or create potentially big holes in the
> stack...

I see over 4MB in a single allocation to be kind of a corner case anyhow.  If you
need to allocate this much memory for a temp variable that doesn't escape the
current scope, in a single allocation (probably pretty unusual already), since the
cost of an allocation is sublinear in bytes allocated, the allocation time will
likely be dwarfed by the time it takes to use the memory for whatever you need it
for.  Furthermore, whether by frameInit/frameFree or by
TempAlloc.malloc/TempAlloc.free, the memory gets freed deterministically rather
than waiting for the GC to run to free it, so it's still faster than using new,
etc.  In fact, I'm thinking I should have made this limit ~1MB (about 1/4 the size
of a TempAlloc block) since allocating 4MB will always require the creation of a
new block anyhow.

I'm open to suggestions about how to deal with these large block cases, but I will
prioritize handling the common case of much smaller allocations efficiently and
cleanly over what I feel is somewhat of a corner case.