hg: panama/panama/jdk: Summary: push of version-2 prototype of Arrays2.0. Work remains, comment is requested.

[Samuel Audet]

Hi, John, David,

Thanks for the feedback!

On 10/08/2014 11:41 AM, David Chase wrote:
>
> On 2014-10-07, at 9:35 PM, John Rose <john.r.rose at oracle.com> wrote:
>> On Oct 7, 2014, at 5:59 PM, Samuel Audet <samuel.audet at gmail.com> wrote:
>>
>>> Is panama-dev going to be the place where most of the discussions about Arrays2.0 take place? Or is this part of some other project?
>>
>> I like to think of Panama as consisting of three major chunks of work:
>> FFI, data layouts, and Arrays 2.0.
>>
>> I gave an early and rough prospectus of the Arrays 2.0 work at
>> the 2012 JVM Language Summit [1] and Karl Taylor and I talked
>> more generally about flattened data structures this year[2].
>>
>> [1]: http://cr.openjdk.java.net/~jrose/pres/201207-Arrays-2.pdf
>> [2]: http://cr.openjdk.java.net/~jrose/pres/201407-FlattenedData.pdf
>
> Note that there’s a reasonable-sized chunk of that Arrays2.0 talk that I have not
> yet addressed — I have focused on multiple (well, 2 — and based on that, I am not
> sure what the best plan for N > 2 is) dimensions, long addressing, bulk operations,
> performance, and extensibility.
>
> I *think* I have a plan for volatile, I think I have a plan for soft-read-only,
> and I’m thinking about what the locking/concurrency world should look like.
>
> Arrays embedded into objects, I have not yet looked into (except as part of a layout prototype),
> I think that is a completely different sort of work (VM hacking, not library hacking — unless we do
> it in Layout).  And I’m not going near the notation till I think I have the mechanisms all working reliably.
>
> And it’s useful feedback to hear “I love the idea of bulk operations with built-in
> fork/join and blocking” or “I really really need the ability to lock ranges of an array”
> or “volatile access to array elements is very important to me”.

This is all very interesting! Right now, I'm not doing much Java as part 
of my day job, unfortunately, but I hope one day to become a "serious" 
user of such features.

Now, from what I can gather from the messages quoted above and what's 
been happening with the developments until now, Panama's priority is 
about actual native functionality for Java, for performance reasons, by 
sort of duplicating the functionality of C, rather than language interop 
with C/C++. Is this assessment correct?

I've been considering Java as a "higher-level environment" than C/C++, 
similarly to how C/C++ is higher-level to assembly language: There are 
platform-specific things that are only accessible from assembly, and 
that will always be the case. So, I thought of it the same way with 
Java, dropping to JNI for things that we can't do in Java. I feel that 
knowing exactly where to draw the line would be the most crucial thing 
to know. If volatile, for example, works exactly the same way across all 
architectures, then sure, that should be in, but if something works 
differently on different platforms and can't be generalized with 
acceptable performance, then that might be something to leave out of 
Java, and handle with C or something.

But I have not given all this a great deal of thought. I'll be sure to 
keep thinking about this though and see how things develop here!

Samuel