Primitive Queue<any T> considerations

[Vitaly Davidovich]

John mentioned Panama and possible synergies with Valhalla, and asked about
layout so I jumped in :).  Defining a struct whose layout matches that of a
piece of memory is highly useful, so we have struct + layout, seemed
relevant :).

sent from my phone
On Nov 18, 2015 10:27 PM, "Richard Warburton" <richard.warburton at gmail.com>
wrote:

> Hi,
>
> Vitaly: so would I but are you sure that that use case should be part of
> Valhalla? It seems highly orthogonal to value types. The only thing they
> have in common is a different memory layout from Java objects.
> On 18 Nov 2015 15:58, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
>
>> 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
>> >
>>
>