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

[David Chase]

On 2014-10-06, at 8:43 PM, Samuel Audet <samuel.audet at gmail.com> wrote:
>> Summary: push of version-2 prototype of Arrays2.0.  Work remains, comment is requested.
> 
> This is very interesting! Thanks for allowing something like this to become eventually part of the JDK.
> 
> One question/comment: Would it be possible to use NIO buffers instead of Java arrays for the underlying data? If we could use NIO buffers, it would help efficiency by allowing us to access native data buffers directly when used along native code, which is basically the goal of the Panama Project.

Thanks for the encouragement.  The answer is yes, it is entirely possible to use NIO buffers for the underlying data, and also on the Panama plan is “Layout” (for lack of a better name) which should allow exactly that, but the Layout design is still TBD in places.

For an example of how you could get there right now by hand if you were sufficiently motivated,
see RowMatrix.CXinL (it’s an inner class, 50 lines starting at line 234 of javax.arrays.v2.RowMatrix.java .
CXinL stands for Complex in Long, and it stores the two float fields of a Complex in a single long, 
using an array of arrays of long to keep it compact.

One thing to note about this design — do not panic about the use of boxed types.  It is forward-looking in two ways (note that as a mere Oracle minion, any predictions I make about the future should be considered to be completely unreliable and in no way likely to ever occur, etc, etc); first, when partial escape analysis is properly implemented wonderful things happen.  The Graal research compiler already has this and has demonstrated its value.  Second, value types and reified generics are considered a good thing to add, and if/when they see the light of day, they should be a big help even when escape analysis is not working so well.

It is possible, though tedious, to write specialized kernels to work around current upside potential in the compiler.  The rest of the framework handles temporary creation and fork/join and also attempts to allocate temporaries with the right locality (for example, second operand of a matrix product wants to be column major), the kernel just needs to handle a “small” iterative case of a portion of a matrix that ought to have simple indexing.

One problem with this prototype is that it really needs some specialization if only in a separate copy of the bytecodes, because if the “leaf kernels” (e.g., javax.arrays.v2.ops.ProductOp) become polymorphic, performance tanks.  That’s one of the things I want to work on next.

David