Primitive Queue<any T> considerations

[John Rose]

On Nov 18, 2015, at 4:35 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> Why do medium sized structs require "buffering" and indirection? Do you mean they're stored on the stack instead of scalarized in registers? If so, sure, no problem.

Check.
> As for the 1000 byte struct, I don't care if "moving" it via heap is faster, I don't want GC pressure :).  If I do this dance enough times and a GC comes along, I may lose any gains and then some that I had via faster movement/access earlier.
> 
This will require some investigation when we get prototypes.
I'm not saying it's impossible, but promising "no GC pressure"
for "1000 byte structs" is low on my priority list.  (But I've got
a few ideas to try when the time comes…)
> As for mutable stack storage (e.g. iterators perfect example), I think it's very important to have some story here.  I've long been advocating for allowing mutable structs, but you'd need to allow passing them by reference as well then.  CLR does this, so it's not some new ground entirely.
> 
> However, I'd be happy with whatever other mechanics as long as the use case is met.
> 

Again, this will require extra work.  It's almost as if we want
a new feature here: Confined objects, which are mutable
and guaranteed to stay thread-local.  (Java has finality
but not confinement; as Brian has written, both are
important concurrency tools.)

The CLR example is not one I want to follow.  I think
their attempt to support both kinds of value types
(mutable, immutable) caused them some problems
we need to avoid.  First, atomicity is not central in
the story.  Also, value aliasing is intermittent and hard
to follow in the code, so that there are puzzlers where
value field writes are invisibly lost, when the value
is a temp.

— John