Primitive Queue<any T> considerations

Vitaly Davidovich vitalyd at gmail.com
Thu Nov 19 02:18:59 UTC 2015


I'd be open to a new feature as well.  Really, I'd like the facility there
with the requisite performance aspects, I'm not married to any particular
mechanics.

Aliasing of mutable value types is an overblown concern, IME.  I've used
them quite a bit in C# and didn't find any puzzlers.  Does one need to be
careful? Sure, but I find myself being more careful in java when trying to
avoid heap allocations and indirection (i.e. copious primitive abuse, byte
buf manual layouts, etc).

Also, you can have "lost" writes even with immutable types, e.g.:

MyMutableInt x = new ...
x.add(...); oops forgot to assign to new local

sent from my phone
On Nov 18, 2015 7:47 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> 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
>


More information about the valhalla-dev mailing list