Stack-allocated arrays

[Sean Kelly]

Andrei Alexandrescu wrote:
> Sean Kelly wrote:
>>
>> It's an implementation detail, but when the owner thread dies it 
>> should null the links for all the list nodes, assuming the data 
>> contained in those nodes can be shared across threads.
> 
> Damn straight it could free() them assuming it has malloc()ated them!

Or delete them if it's newed them :-)  Assuming we want the GC to 
potentially scan at least some of these superblocks.

>> I suppose I'm wondering what the advantage is of this approach over 
>> simply using dynamic memory.
> 
> Speed. An allocation/deallocation is most of the time a counter bump and 
> a check.

Gotcha.
> 
>> Is it the fact that allocations are non-locking?
> 
> No.
> 
>> Pure stack allocations make sense because all such allocations are 
>> scoped and guaranteed to be extremely fast.  So I suppose this is 
>> simply a parallel local "stack" for the same purpose and the goal is 
>> to avoid the assembly magic necessary for an alloca() type solution?  
>> And if this is the case, then I assume that sharing would be illegal 
>> (at least on D2)?
> 
> It is better than the stack because it can tap into the entire heap, as 
> opposed to whatever was reserved for the stack. You can also expand an 
> array on the superstack, whereas you can't with alloca. (I forgot to 
> provide that primitive.) Yah, and indeed recall that D2 is all built 
> around no implicit sharing across threads.

Makes sense.  I think stack allocations tend to get a bit weird if you 
ask for more than a page or so of memory anyway.

>> My initial reaction is that I'm skeptical of any attempt at manual 
>> replacement of built-in functionality.  It's been shown, for example, 
>> that custom allocators often perform worse than the default allocators.
> 
> I seem to recall that. Oh, wait, I gave a talk on that, several times 
> :o). Emery Berger studied the problem. It turns out user-defined heaps 
> are usually worse off, with one exception: regions. SuperStack is a 
> region. That's why I'm counting it could make a difference.

Fair enough :-)

>>  That aside, the general approach does seem reasonable.  Though I'd 
>> still prefer we just get real stack-based dynamic allocation in D.  It 
>> seems quite natural that "scope" should provide this for arrays as a 
>> QOI feature, as it does for classes.
> 
> I agree. There are a few problems. One is that loops can make things 
> tricky, as you need to call alloca only once. The other has to do with 
> the way Walter generates code, I forgot the details, but it's fixable if 
> some time is invested. And the third is, as I said, stack allocation can 
> actually fail long before the system runs out of memory. It has happened 
> to me.

Sounds like it's worth doing then.  At worst it makes for an easy 
search/replace later if we get this feature natively.  I'd certainly use 
it anyway.  I currently use alloca() or new/delete depending on the 
situation, and it seems convenient to flatten all this into the use of a 
specialized library module.


Sean