IntVector implementation

[Graves, Ian L]

> FYI I've just pushed register allocator aware code snippet prototype into the panama forest [1] [2].

Awesome!  I really like the way these work.

> It looks very nice! I like how it shapes out.

Thanks!  It seems to be following a predictable pattern.

> I don't see any vector type checks in the code.
> Java generics aren't enough to ensure type safety (Vector<Integer, Shapes.S128Bit>). So, some vector operations should perform type checks at runtime to ensure the parameters have compatible shape.

I can take a crack at adding in checks.  The non-public toLongN() group of methods can save us some checking, but I'm not sure how strict we want to be there.

> Have you had a chance to play with different vector sizes?

I have been doing exploratory coding with some Vector<Float,Shapes.S256Bit> implementations and mixing them with views.  There is a more eager standalone 256 bit float Vector like the integer one, and there is a lazy 256 bit float vector for use with a view.  I'm curious about using the VectorAPI as a way to direct work at the LongN-level and avoid dealing in concrete instances of Vector at all (at the user level).  I can share some of this when it's cleaned up.

> I'm curious how does the JIT behave when optimizing such checks.
> Ideally, it should common the checks and perform them only once.

I'm also curious about this.  I want to start some performance analysis and looking at generated code soon to get a feel for what happens here.

> Do you mind if I integrate it into the panama forest?

No problem.  Feel free to integrate it.

Thanks!

--Ian

> [1] http://hg.openjdk.java.net/panama/panama/hotspot/rev/fb6532ac7731
> [2] http://hg.openjdk.java.net/panama/panama/jdk/rev/1a60ef85ddba