Primitive Queue<any T> considerations

[John Rose]

On Nov 18, 2015, at 12:38 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> A large point of value types
> is they do not touch the heap, and thus do not contribute to any subsequent
> GC pauses.  If I had a large struct, I may be just fine having a slower
> copy operation percolating through the stack.  This is like escape
> analysis, nobody that's avoiding GC is actually relying on it because of
> this "VM's choice" aspect.  I urge you to reconsider this automatic boxing
> aspect.  Nobody is going to complain that the JVM is not automatically
> boxing their large struct, but someone will complain if there's heap
> allocation behind the scenes.

This is an interesting question, especially since early prototyping
of value types may involve a surprising amount of boxing,
particularly for "hard cases" like the large struct you mention.

The above is a good argument to remember, though.
I suppose you mean copies between locals:  Those
should not copy through the heap, in common cases.
A non-small value type will probably need buffering,
but the buffer can be allocated using stack rules,
refcount rules, or the like, so it can be deallocated
in a timely manner without GC interaction.

(BTW, it is possible we will decide that de-opt
transitions will use heap copies, at least at first.)

It seems there are three interesting value type sizes.
Small ones fit in a register or two, and/or can be
atomically loaded and stored by hardware.
Large ones span multiple cache lines, and
have only limited benefit compared to objects.
In the middle, the medium ones require several
instructions to store (and extra work for atomicity)
but still occupy the natural unit of memory, which
is a cache line (or two, relying on prefetch).

> they do not touch the heap


Value types can touch the heap in various use cases,
in the same way that ints can be stored in the heap,
or (new to value types) in that they can contain refs.

It is true that using value types will reduce GC load in
many cases (besides local-to-local copies), but this
is mainly because of their flatness, which reduces
memory pressure and decreases frequency of
dependent loads.

— John