Primitive Queue<any T> considerations

[Vitaly Davidovich]

Personally, I'd love to see layout and alignment exposed.  I'd also like to
see something like this Slice:
https://github.com/joeduffy/slice.net/blob/master/README.md.  Being able to
overlay a typesafe and cheap struct on top of a byte buffer would save some
boilerplate coding.

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

> On Nov 18, 2015, at 12:36 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>
> Note that while values are in part about getting flatter data layouts, we
> do not plan to offer anything in the way of fine-grained layout control,
> such as allowing for explicit alignment requirements.  (Though other
> efforts, such as Project Panama, may have something to offer here).
>
>
> Right; it's easier on the JVM to let it have its own choice on layouts.
>
> For example, HotSpot usually repacks object fields so that refs
> are all together, longs/doubles all together, ints/floats together,
> etc., to minimize fragmentation and certain GC overheads.
> Value types are likely to play such games also.
>
> Open question:  How valuable would it be to "export" JVM-laid-out
> values off heap?  My take:  Not a killer feature if done via bitwise
> copies, since off-heap storage often needs an externally defined
> layout.  But, perhaps we could define a mapping (or several
> mappings) from value types to native types, and build copy
> operations into Panama.  Simple types like complex<double>
> should copy bitwise between heaps, even other types like
> tuple<long, boolean, long> do not.  The main point is that
> Panama expects to take data schemas from multiple
> sources (not just C/C++), and that will play well with
> value types.
>
> — John
>