Irgendwie fühle ich mich angesprochen 
Aber es ist schwer, etwas fundiertes dazu zu sagen. Ich bin zwar schon lange z.B. bei der Panama Mailing List registriert, muss aber zugeben: Es ist ((für mich) zu) viel. Ich habe gerade mal in meinen Mails runtergescrollt zum relevante(st)en markierten/ungelesenen Beitrag, und der war notes on binding C++ . Allen relevanten Projekten tatsächlich in aller Tiefe zu folgen, das nachzuvollziehen und sogar zu bewerten oder etwas beizutragen könnte beliebig viel Zeit in Anspruch nehmen. Deswegen würde ich eher einen Vortrag auf einer Konferenz hören wollen, wo mal innerhalb kurzer Zeit ein kompakter Wrap-Up über den letzten Stand, ohne viel Gelaber gemacht wird…
Die großen (und teilweise recht nah verwandten) Punkte sind ja wohl
Bei den meisten hatte ich schon einiges gelesen (z.B. die frühen proposals zu den Value Types auf Value Types for Java ), aber auf dem neuesten Stand in bezug der Antworten auf die dort aufgeworfenen Fragen bin ich nicht.
Inwieweit die Projekte sich untereinander koordinieren oder abstimmen, ist schwer zu sagen. Aber bei der personellen Überschneidung, die es da gibt, sollte das wohl selbstverständlich (bis hin zu „nicht nötig“) sein 
.
Etwas aus der Reihe fällt Sumatra oben schon: Das passiert im Hotspot JIT, und hat nichts mit einer API zu tun. Aber der Grund, warum ich es hinzugefügt habe, sollte klar sein: Das Ziel von JCuda und JOCL ist gerade, die existierenden GPU-Libraries per JNI nutzbar zu machen. In diesem Sinne kann man die Ziele der anderen beiden Projekte einordnen.
#Foreign Function Interface
Dass zum Ansprechen der existierenden Libraries etliche Megabytes (!) JNI-Code notwendig sind, grenzt ans absurde. Viel von dem Code ist automatisch generiert, und das ist der Punkt: Er kann automatisch generiert werden! In den allermeisten Fällen wird dort nichts weiter gemacht, als die Java-Parameter (int, float…) über die JNI-Schicht (jint, jfloat…) an die C/C+±Funktion (int32_t, float…) weiterzureichen.
Spannender wird es natürlich bei nicht-primitiven Typen. Auch da kann die Übersetzung oft weitgehend automatisch gemacht werden - etwa bei einfachen structs - aber auch da gibt es schon Caveats, wie etwa Alignment und Padding. Wenn ich sehe, wie das teilweise gehandhabt wird (etwa bei LWJGL oder JavaCPP) schaudert es mir. (Das ist nicht wertend!!! Es gibt einfach keine andere (generische!) Möglichkeit!). Aber richtig schwierig wird es bei komplexeren Strukturen, wie echten (ggf. virtuellen) Klassen, oder Function Pointers…
Kurz: Ein echtes, generisches FFI ist schwierig, weil bestimmte Konstrukte nur schwer sprachübergreifend übersetzbar sind.
Interessanterweise gab es in den ersten Versionen der JNI-Doku ein Kapitel dazu. Das Kapitel wurde irgendwann weggelassen, und ist darum hier nur über das WebArchive verlinkt: Leveraging Existing Native Libraries Dort steht, wie man so ein generisches Interface basteln kann … mit einigem an magischem Inline-Assembler 
(Ich werde wohl früher oder später mal auf stackoverflow fragen, warum das weggelassen wurde. Die Frage wäre ein Kandidat für Downvotes und Close Requests, aber … manchmal antworten dort auch Leute wie Rose und Goetz, vielleicht könnten die etwas Einsicht bringen… 
)
#Vector Operations
Diese beziehen sich, soweit ich das bisher verstanden habe, hauptsächlich auf Instruction-Level-Parallelism. (Aber muss zugeben, da vieles bisher noch nicht in der nötigen Tiefe gelesen zu haben). Der Grund, weswegen ich da eine Parallele zu den anderen Themen sehe ist, etwas oberflächlich gespochen: Die GPU bietet genau solche Vector Operations an! Nicht zuletzt deswegen hatte ich irgendwann mal GitHub - jcuda/jcuda-vec: Vector operations for JCuda erstellt. Wenn sowas in Zukunft ohne JCuda, CUDA und die JNI-Schicht möglich wäre, und von der JVM direkt unterstützt würde, und damit direkt von der JVM entweder auf der CPU oder der GPU ausgeführt würde, wäre das super.
(Darüber schwebt wie ein Damoklesschwert die Frage nach dem Speicherbereich: Wenn es auf der GPU ausgeführt werden soll, müssen die Daten im Device Memory liegen. Wenn der JIT die Daten dann wild zwischen GPU und CPU hin-und-her kopieren müsste, würde das nicht sooo viel bringen Aber es gibt mit dem „Unified Memory“ oder „Mapped Memory“, und dem, was die HSA-Foundation macht, einige Hoffnung, dass schon sehr bald die GPU und die CPU auf den selben Speicher zugreifen können, von daher ist dieses Damoklessschwert vielleicht gar nicht so spitz und bedrohlich, wie es im ersten Moment aussieht).
#Value Types
Ein sehr wichtiger und interessanter Punkt. An verschiedenen Stellen musste ich schon erklären, warum die Leute ihren
class Point {
float x,y,z;
}
Point points[] = new Point[100];
array eben nicht so auf die GPU rüberkopieren und dort als
struct Point {
float x,y,z;
}
Point points[100];
array verwenden können. (Dabei sieht der Code doch sooo ähnlich aus!). Den Grund hast du ja auch in den Folien beschrieben: Die Point-Objekte liegen in Java potentiell im ganzen Heap verteilt. Um sowas „gut“ auf die C+±Seite mappen zu können, muss man sicherstellen können, dass man auch in Java einen einzigen, verläßlichen Memory-Block hat, dessen Layout genau mit dem auf der C-Seite übereinstimmt (und der idealerweise nicht beliebig vom GC in der Gegend rumbewegt werden kann - aber das ist ein weiterer, so gesehen unabhängiger Punkt).
Nochmal: Der aktuelle Stand der Ansätze (z.B. das mit den Layout-Klassen, die in den Folien angedeutet sind), kenne ich nicht - und noch weniger die interne Umsetzung. Aber das sind alles Punkte, die, wenn sie vernünftig umgesetzt sind und schön zusammenspielen (!) etliche neue, interessante Möglichkeiten bieten könnten (und vielleicht auch JCuda und JOCL überflüssig machen, aber wenn damit alles „besser und einfacher“ wird, wäre das schon OK )
und sei es nur als POC, als Tribut an Sumatra…)