Vector API "Straw Man" Boxed/Unboxed Vector Instantiation

[Graves, Ian L]

The question of IR for the HOF components raises some important questions.  The mapping and zipping (mapWhere + BinaryOperation) functionalities are particularly amenable to supporting user-directed vector operations coming from some kind of source.  Doing it with lambdas is the most natural way to go about it here, but there are some challenges with this approach.  John mentioned "lambda cracking" where we (from my understanding) are looking reify the program body inside of a given lambda so we can reinterpret/recompile it into low level vector operations (ex. CodeSnippets).  

One  caveat I can think of is that we would have corner cases in Java involving effectful expressions (assignment, ++, +=, for example) that we would potentially have to exclude from the Vector domain.  Could this be something that we could perform at compile time?  It seems unnatural to let something like one's use of "+=" slip through compilation and then cause a runtime error, though it's probably fair to say that code is being re-evaluated at runtime so all bets are off.  Another issue is how we should treat variable capture in this context.  I'm not sure how C# does it in general, but for Vectors we may have some issues with other types of legal expressions like invocations could crop up.

Incidentally I've been sketching around on an abstract interpretation-based approach as an alternative to the cracking problem, and my process tends to end up with some IR similar to C#'s Expression class.  I think such an approach could work, but wouldn't be as natural as pure Java expressions.  The one advantage of abstract interpretation is that we can control the instances and operations more easily, and without anything as major as lambda cracking.  Perhaps it might be a good stop gap measure to build up this approach on an IR that we could pivot to use for more general lambda cracking?

The expression trees solution seems like a really neat idea to me and something I'd like to talk more about in whichever forum is appropriate (not sure if Panama is the place for it).

-- Ian
 
-----Original Message-----
From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On Behalf Of John Rose
Sent: Monday, March 28, 2016 12:58 PM
To: panama <panama at zeus.net.au>
Cc: panama-dev at openjdk.java.net
Subject: Re: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation

On Mar 26, 2016, at 4:45 PM, panama <panama at zeus.net.au> wrote:
> 
> How can spir-v be leveraged? Could the vector api utilise it? Could hotspot support spir-v, in case it wasn't supported by underlying hardware?

The library engines behind Vector could maybe use something like SPIR.  (And the IR might leak through in interesting ways to some users.)

This relates to my comment that we need a way for the Vector runtime to "crack" the lambdas passed to HOF API points like Vector.reduce.  If we had the equivalent of C# expression trees, we could treat chains of vector ops as queries to be optimized, when executing a terminal operation (such as Vector.intoArray or hypothetical Vector.collect).  A vector expression could be cooked into some kind of IR, and then instruction-selected into a AVX code.

To use SPIR (or maybe even the above approach), we would need a more explicit user-cotrolled boundary between the "host" and "offload" parts of the computation.  Making an automagic partition between the two, from a common bucket of Java execution, is currently science fiction.

— John