From ian.l.graves at intel.com Tue Mar 1 23:19:07 2016 From: ian.l.graves at intel.com (Graves, Ian L) Date: Tue, 1 Mar 2016 23:19:07 +0000 Subject: Rough prototype of a Vector API In-Reply-To: References: Message-ID: Hi Paul, This is pretty cool! I've been working on an int[] view over Long2 that I can put up once it's a little less rough. It looks fairly similar to your approach. I will try to harmonize it with your naming style. Additionally, I've tweaked my Vector interface to include a few more arithmetic and logical methods, but I can pare that back for the time being (or permanently!). What would be a good/preferred method for me to share what I've got with this list when I am ready? One quick thought to the note about imm's being hard-coded into snippets. > - Instructions requiring immediate values have to be hard coded in a code snippet. For insertion or extraction of a byte value to/from a Vector i defer to the ?pinsrb? and ?pextrb? instructions respectively. I create 16 MHs for each kind :-) where the index is encoded as an immediate. This obviously does not scale, nor is it visible to the JIT. Perhaps the Patchable CodeSnippet approach is robust enough to hoist whole values into an imm position? I don't want to put too much weight on what is already a pretty clean interface, but it does seem like it could work. --Ian From mikael.vidstedt at oracle.com Wed Mar 2 18:27:25 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Wed, 02 Mar 2016 18:27:25 +0000 Subject: hg: panama/panama/hotspot: Fix build problem related to NativeEntryPoint and oop.inline.hpp Message-ID: <201603021827.u22IRQTD007776@aojmv0008.oracle.com> Changeset: 14ade5b4930d Author: mikael Date: 2016-03-02 10:27 -0800 URL: http://hg.openjdk.java.net/panama/panama/hotspot/rev/14ade5b4930d Fix build problem related to NativeEntryPoint and oop.inline.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp From vladimir.x.ivanov at oracle.com Thu Mar 3 21:38:12 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 4 Mar 2016 00:38:12 +0300 Subject: Rough prototype of a Vector API In-Reply-To: References: Message-ID: <56D8AEC4.3020907@oracle.com> Ian, > This is pretty cool! I've been working on an int[] view over Long2 that I can put up once it's a little less rough. It looks fairly similar to your approach. I will try to harmonize it with your naming style. Additionally, I've tweaked my Vector interface to include a few more arithmetic and logical methods, but I can pare that back for the time being (or permanently!). What would be a good/preferred method for me to share what I've got with this list when I am ready? It would be great if you could just push it into panama repository. There's no strict integration rules in the project. Or sharing patches as webrevs also works fine. Meanwhile, until you aren't Panama Committer, I (or anybody with enough privileges) can assist you (with sponsoring your changes or putting webrevs on cr.ojn server until you get an account). Just send patches my way. > One quick thought to the note about imm's being hard-coded into snippets. > >> - Instructions requiring immediate values have to be hard coded in a code snippet. For insertion or extraction of a byte value to/from a Vector i defer to the ?pinsrb? and ?pextrb? instructions respectively. I create 16 MHs for each kind :-) where the index is encoded as an immediate. This obviously does not scale, nor is it visible to the JIT. > > Perhaps the Patchable CodeSnippet approach is robust enough to hoist whole values into an imm position? I don't want to put too much weight on what is already a pretty clean interface, but it does seem like it could work. I haven't thought it through, but there are some complications. Though it looks simple for patchable snippets, the hard part is stand-alone versions for interpreter/C1. You have to dispatch on the parameter value and generate all necessary specializations. I'd prefer to see that logic in a Java library than in machine code or JVM. So far, I explicitly instantiated all specializations [1]: static final MethodHandle MHm128_insert_epi32_0 = make_m128_insert_epi32(0); static final MethodHandle MHm128_insert_epi32_1 = make_m128_insert_epi32(1); static final MethodHandle MHm128_insert_epi32_2 = make_m128_insert_epi32(2); static final MethodHandle MHm128_insert_epi32_3 = make_m128_insert_epi32(3); and dispatched between them in the library function: public static Long2 insert_epi32(Long2 v, int x, int off) { try { MHm128_insert_epi32[off].invokeExact(v, x); switch(off) { case 0: return (Long2) MHm128_insert_epi32_0.invokeExact(v, x); case 1: return (Long2) MHm128_insert_epi32_1.invokeExact(v, x); case 2: return (Long2) MHm128_insert_epi32_2.invokeExact(v, x); case 3: return (Long2) MHm128_insert_epi32_3.invokeExact(v, x); default: throw new IllegalArgumentException(""+off); } } catch (Throwable e) { throw new Error(e); } } It is easily optimizable by JITs. A cleaner way would be to put them all in the @Stable array: static @Stable final MethodHandle[] MHm128_insert_epi32 = new MethodHandle[] { make_m128_insert_epi32(0), make_m128_insert_epi32(1), make_m128_insert_epi32(2), make_m128_insert_epi32(3)}; public static Long2 insert_epi32_1(Long2 v, int x, int off) { try { return (Long2) MHm128_insert_epi32[off].invokeExact(v, x); } catch (Throwable e) { throw new Error(e); } } It also allows to lazily instantiate specializations and JIT can easily constant-fold and inline snippets through the @Stable array when offset is compile-time constant. But @Stable is part of JDK internals, so I decided to keep away from it for now. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/panama/panama/jdk/file/2dddc1a1b55d/test/panama/snippets/VectorUtils.java#l260 From paul.sandoz at oracle.com Fri Mar 4 09:22:42 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Mar 2016 10:22:42 +0100 Subject: Rough prototype of a Vector API In-Reply-To: <56D8AEC4.3020907@oracle.com> References: <56D8AEC4.3020907@oracle.com> Message-ID: <93B9F179-93FD-47CB-98DD-09E4580B1D46@oracle.com> > On 3 Mar 2016, at 22:38, Vladimir Ivanov wrote: > > Ian, > >> This is pretty cool! I've been working on an int[] view over Long2 that I can put up once it's a little less rough. It looks fairly similar to your approach. I will try to harmonize it with your naming style. Additionally, I've tweaked my Vector interface to include a few more arithmetic and logical methods, but I can pare that back for the time being (or permanently!). What would be a good/preferred method for me to share what I've got with this list when I am ready? > It would be great if you could just push it into panama repository. There's no strict integration rules in the project. Or sharing patches as webrevs also works fine. Yes. Feel free to dive in and change as you see fit, there is nothing set in stone here e.g. including the package name, it should be more generic, or structure (I dumped a maven project with unit tests because i find it more efficient to work in that manner, so much easier/faster to run/test/debug than viewing as a subset of the larger JDK project and execution with jtreg). > > Meanwhile, until you aren't Panama Committer, I (or anybody with enough privileges) can assist you (with sponsoring your changes or putting webrevs on cr.ojn server until you get an account). Just send patches my way. Likewise :-) > >> One quick thought to the note about imm's being hard-coded into snippets. >> >>> - Instructions requiring immediate values have to be hard coded in a code snippet. For insertion or extraction of a byte value to/from a Vector i defer to the ?pinsrb? and ?pextrb? instructions respectively. I create 16 MHs for each kind :-) where the index is encoded as an immediate. This obviously does not scale, nor is it visible to the JIT. >> >> Perhaps the Patchable CodeSnippet approach is robust enough to hoist whole values into an imm position? I don't want to put too much weight on what is already a pretty clean interface, but it does seem like it could work. > I haven't thought it through, but there are some complications. Though it looks simple for patchable snippets, the hard part is stand-alone versions for interpreter/C1. You have to dispatch on the parameter value and generate all necessary specializations. > > I'd prefer to see that logic in a Java library than in machine code or JVM. > Ok. To me it seems quite a fundamental operation, but perhaps it is actually rare in some sense, if one has to loop to extract, apply, insert it implies one should be using a more optimal instruction, so that style is an escape-hatch for something that may be missing (or to verify equivalence via an assertion). > So far, I explicitly instantiated all specializations [1]: > Yes, same here, i did not realize you did the same thing in VectorUtils.java. It seems useful to consolidate all snippets in such a class and place it within a JDK package making it more widely usable to tests and other experiments. How about in say an exported package jdk.nicl.x86.snippets? (Then we can also use @Stable if so desired.) Paul. > static final MethodHandle MHm128_insert_epi32_0 = make_m128_insert_epi32(0); > static final MethodHandle MHm128_insert_epi32_1 = make_m128_insert_epi32(1); > static final MethodHandle MHm128_insert_epi32_2 = make_m128_insert_epi32(2); > static final MethodHandle MHm128_insert_epi32_3 = make_m128_insert_epi32(3); > > and dispatched between them in the library function: > > public static Long2 insert_epi32(Long2 v, int x, int off) { > try { > MHm128_insert_epi32[off].invokeExact(v, x); > switch(off) { > case 0: return (Long2) MHm128_insert_epi32_0.invokeExact(v, x); > case 1: return (Long2) MHm128_insert_epi32_1.invokeExact(v, x); > case 2: return (Long2) MHm128_insert_epi32_2.invokeExact(v, x); > case 3: return (Long2) MHm128_insert_epi32_3.invokeExact(v, x); > default: throw new IllegalArgumentException(""+off); > } > } catch (Throwable e) { > throw new Error(e); > } > } > > It is easily optimizable by JITs. > > A cleaner way would be to put them all in the @Stable array: > > static @Stable final MethodHandle[] MHm128_insert_epi32 = new MethodHandle[] { > make_m128_insert_epi32(0), > make_m128_insert_epi32(1), > make_m128_insert_epi32(2), > make_m128_insert_epi32(3)}; > > public static Long2 insert_epi32_1(Long2 v, int x, int off) { > try { > return (Long2) MHm128_insert_epi32[off].invokeExact(v, x); > } catch (Throwable e) { > throw new Error(e); > } > } > > It also allows to lazily instantiate specializations and JIT can easily constant-fold and inline snippets through the @Stable array when offset is compile-time constant. > > But @Stable is part of JDK internals, so I decided to keep away from it for now. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/panama/panama/jdk/file/2dddc1a1b55d/test/panama/snippets/VectorUtils.java#l260 From mikael.vidstedt at oracle.com Tue Mar 8 18:32:32 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Tue, 08 Mar 2016 18:32:32 +0000 Subject: hg: panama/panama/scratch: Refactoring in preparation for upcall testing Message-ID: <201603081832.u28IWWvK006542@aojmv0008.oracle.com> Changeset: 332bf7fe84ae Author: mikael Date: 2016-03-08 10:30 -0800 URL: http://hg.openjdk.java.net/panama/panama/scratch/rev/332bf7fe84ae Refactoring in preparation for upcall testing ! jdk.internal.nicl.testgen/Makefile ! jdk.internal.nicl.testgen/make/Generator.gmk ! jdk.internal.nicl.testgen/make/Tests.gmk ! jdk.internal.nicl.testgen/src/main/java/generator/AbstractFile.java ! jdk.internal.nicl.testgen/src/main/java/generator/BasicType.java + jdk.internal.nicl.testgen/src/main/java/generator/CaptureFunction.java + jdk.internal.nicl.testgen/src/main/java/generator/Constants.java ! jdk.internal.nicl.testgen/src/main/java/generator/CopyrightHeader.java + jdk.internal.nicl.testgen/src/main/java/generator/DowncallFunction.java ! jdk.internal.nicl.testgen/src/main/java/generator/FileContents.java ! jdk.internal.nicl.testgen/src/main/java/generator/Function.java ! jdk.internal.nicl.testgen/src/main/java/generator/GenerateTestFiles.java ! jdk.internal.nicl.testgen/src/main/java/generator/HeaderFile.java ! jdk.internal.nicl.testgen/src/main/java/generator/IfdefGuard.java ! jdk.internal.nicl.testgen/src/main/java/generator/ImplFile.java ! jdk.internal.nicl.testgen/src/main/java/generator/IncludeDependency.java + jdk.internal.nicl.testgen/src/main/java/generator/StructCaptureFunction.java ! jdk.internal.nicl.testgen/src/main/java/generator/StructEntry.java + jdk.internal.nicl.testgen/src/main/java/generator/StructWalkerFunction.java + jdk.internal.nicl.testgen/src/main/java/generator/UpcallFunction.java ! jdk.internal.nicl.testgen/src/main/java/runner/TestRunner.java ! jdk.internal.nicl.testgen/src/main/native/verifier.c ! jdk.internal.nicl.testgen/src/main/native/verifier.h From mikael.vidstedt at oracle.com Thu Mar 10 00:20:35 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Thu, 10 Mar 2016 00:20:35 +0000 Subject: hg: panama/panama/scratch: Initial skeleton for supporting upcall testing Message-ID: <201603100020.u2A0KZiK027152@aojmv0008.oracle.com> Changeset: c033a1aba53c Author: mikael Date: 2016-03-09 16:20 -0800 URL: http://hg.openjdk.java.net/panama/panama/scratch/rev/c033a1aba53c Initial skeleton for supporting upcall testing + jdk.internal.nicl.testgen/src/main/java/generator/ArrayVariable.java ! jdk.internal.nicl.testgen/src/main/java/generator/CaptureFunction.java ! jdk.internal.nicl.testgen/src/main/java/generator/DowncallFunction.java ! jdk.internal.nicl.testgen/src/main/java/generator/Function.java ! jdk.internal.nicl.testgen/src/main/java/generator/GenerateTestFiles.java ! jdk.internal.nicl.testgen/src/main/java/generator/StructWalkerFunction.java ! jdk.internal.nicl.testgen/src/main/java/generator/UpcallFunction.java + jdk.internal.nicl.testgen/src/main/java/generator/Variable.java + jdk.internal.nicl.testgen/src/main/java/runner/CallbackWeaver.java + jdk.internal.nicl.testgen/src/main/java/runner/DataGenerator.java + jdk.internal.nicl.testgen/src/main/java/runner/DataVerifier.java + jdk.internal.nicl.testgen/src/main/java/runner/Logger.java + jdk.internal.nicl.testgen/src/main/java/runner/StructWalker.java ! jdk.internal.nicl.testgen/src/main/java/runner/TestRunner.java + jdk.internal.nicl.testgen/src/main/java/runner/Util.java From mikael.vidstedt at oracle.com Thu Mar 10 22:35:52 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Thu, 10 Mar 2016 22:35:52 +0000 Subject: hg: panama/panama/scratch: Support for upcalls (disabled by default) Message-ID: <201603102235.u2AMZq4a023858@aojmv0008.oracle.com> Changeset: d2880fc6c1e5 Author: mikael Date: 2016-03-10 14:35 -0800 URL: http://hg.openjdk.java.net/panama/panama/scratch/rev/d2880fc6c1e5 Support for upcalls (disabled by default) ! jdk.internal.nicl.testgen/src/main/java/generator/UpcallFunction.java - jdk.internal.nicl.testgen/src/main/java/runner/CallbackWeaver.java ! jdk.internal.nicl.testgen/src/main/java/runner/TestRunner.java ! jdk.internal.nicl.testgen/src/main/native/verifier.c ! jdk.internal.nicl.testgen/src/main/native/verifier.h From mikael.vidstedt at oracle.com Fri Mar 11 00:41:36 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Fri, 11 Mar 2016 00:41:36 +0000 Subject: hg: panama/panama/scratch: Fixes for upcalls, now enabled by default Message-ID: <201603110041.u2B0faqx013338@aojmv0008.oracle.com> Changeset: 39b7b733c35d Author: mikael Date: 2016-03-10 16:41 -0800 URL: http://hg.openjdk.java.net/panama/panama/scratch/rev/39b7b733c35d Fixes for upcalls, now enabled by default ! jdk.internal.nicl.testgen/src/main/java/generator/DowncallFunction.java ! jdk.internal.nicl.testgen/src/main/java/generator/UpcallFunction.java ! jdk.internal.nicl.testgen/src/main/java/runner/DataGenerator.java ! jdk.internal.nicl.testgen/src/main/java/runner/TestRunner.java ! jdk.internal.nicl.testgen/src/main/native/verifier.c ! jdk.internal.nicl.testgen/src/main/native/verifier.h From mikael.vidstedt at oracle.com Fri Mar 11 19:02:33 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Fri, 11 Mar 2016 19:02:33 +0000 Subject: hg: panama/panama/jdk: Fixes to support generic upcalls Message-ID: <201603111902.u2BJ2X1O018583@aojmv0008.oracle.com> Changeset: d3f75cd6fdb8 Author: mikael Date: 2016-03-11 11:02 -0800 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/d3f75cd6fdb8 Fixes to support generic upcalls ! src/java.base/share/classes/jdk/internal/nicl/MethodImplGenerator.java ! src/java.base/share/classes/jdk/internal/nicl/NativeLibraryImpl.java ! src/java.base/share/classes/jdk/internal/nicl/StructUtil.java ! src/java.base/share/classes/jdk/internal/nicl/UnixLibrary.java ! src/java.base/share/classes/jdk/internal/nicl/UnixLibraryFactory.java ! src/java.base/share/classes/jdk/internal/nicl/UpcallHandler.java ! src/java.base/share/classes/jdk/internal/nicl/VarargsInvoker.java ! src/java.base/share/classes/jdk/internal/nicl/abi/ArgumentBinding.java ! src/java.base/share/classes/jdk/internal/nicl/abi/CallingSequence.java ! src/java.base/share/classes/jdk/internal/nicl/abi/sysv/x64/Constants.java ! src/java.base/share/classes/jdk/internal/nicl/abi/types/FunctionType.java ! src/java.base/share/classes/jdk/internal/nicl/abi/types/Types.java ! test/java/nicl/abi/sysv/x64/CallingSequenceBuilderTest.java From mikael.vidstedt at oracle.com Fri Mar 11 21:35:52 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Fri, 11 Mar 2016 21:35:52 +0000 Subject: hg: panama/panama/scratch: Enable testing of upcalls returning structs Message-ID: <201603112135.u2BLZqCO015929@aojmv0008.oracle.com> Changeset: 9d899f83eef1 Author: mikael Date: 2016-03-11 13:35 -0800 URL: http://hg.openjdk.java.net/panama/panama/scratch/rev/9d899f83eef1 Enable testing of upcalls returning structs ! jdk.internal.nicl.testgen/src/main/java/generator/DowncallFunction.java ! jdk.internal.nicl.testgen/src/main/java/generator/UpcallFunction.java ! jdk.internal.nicl.testgen/src/main/java/runner/TestRunner.java ! jdk.internal.nicl.testgen/src/main/native/verifier.c ! jdk.internal.nicl.testgen/src/main/native/verifier.h From mikael.vidstedt at oracle.com Fri Mar 11 21:37:57 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Fri, 11 Mar 2016 21:37:57 +0000 Subject: hg: panama/panama/jdk: Support for functional interface methods returning structs Message-ID: <201603112137.u2BLbvBQ016655@aojmv0008.oracle.com> Changeset: 827c3aaa2694 Author: mikael Date: 2016-03-11 13:37 -0800 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/827c3aaa2694 Support for functional interface methods returning structs ! src/java.base/share/classes/jdk/internal/nicl/UpcallHandler.java From henry.jen at oracle.com Sat Mar 12 07:03:05 2016 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Sat, 12 Mar 2016 07:03:05 +0000 Subject: hg: panama/panama/jdk: Support whitespace and comment Message-ID: <201603120703.u2C7352Q007581@aojmv0008.oracle.com> Changeset: d7c0867efa42 Author: henryjen Date: 2016-03-11 22:52 -0800 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/d7c0867efa42 Support whitespace and comment Common types constant in Types Reorganize code to internal package - src/java.base/share/classes/java/nicl/types/Descriptor.java - src/java.base/share/classes/java/nicl/types/Type.java - src/java.base/share/classes/java/nicl/types/TypeUtils.java + src/java.base/share/classes/jdk/internal/nicl/types/Array.java + src/java.base/share/classes/jdk/internal/nicl/types/BitFields.java + src/java.base/share/classes/jdk/internal/nicl/types/Container.java + src/java.base/share/classes/jdk/internal/nicl/types/Descriptor.java + src/java.base/share/classes/jdk/internal/nicl/types/Function.java + src/java.base/share/classes/jdk/internal/nicl/types/Pointer.java + src/java.base/share/classes/jdk/internal/nicl/types/Scalar.java + src/java.base/share/classes/jdk/internal/nicl/types/Type.java + src/java.base/share/classes/jdk/internal/nicl/types/TypeUtils.java + src/java.base/share/classes/jdk/internal/nicl/types/Types.java ! test/java/nicl/types/DescriptorTest.java From mikael.vidstedt at oracle.com Mon Mar 21 21:40:37 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Mon, 21 Mar 2016 21:40:37 +0000 Subject: hg: panama/panama/scratch: Util.isCStruct() Message-ID: <201603212140.u2LLebEZ007257@aojmv0008.oracle.com> Changeset: 62a004491440 Author: mikael Date: 2016-03-21 14:40 -0700 URL: http://hg.openjdk.java.net/panama/panama/scratch/rev/62a004491440 Util.isCStruct() ! jdk.internal.nicl.testgen/src/main/java/runner/DataVerifier.java ! jdk.internal.nicl.testgen/src/main/java/runner/Util.java From mikael.vidstedt at oracle.com Mon Mar 21 21:45:59 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Mon, 21 Mar 2016 21:45:59 +0000 Subject: hg: panama/panama/jdk: Use Util.isCStruct() and Util.sizeof() Message-ID: <201603212145.u2LLjxLv009240@aojmv0008.oracle.com> Changeset: 841c137d31b3 Author: mikael Date: 2016-03-21 14:44 -0700 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/841c137d31b3 Use Util.isCStruct() and Util.sizeof() ! src/java.base/share/classes/jdk/internal/nicl/MethodImplGenerator.java ! src/java.base/share/classes/jdk/internal/nicl/NativeLibraryImpl.java ! src/java.base/share/classes/jdk/internal/nicl/StructImplGenerator.java ! src/java.base/share/classes/jdk/internal/nicl/StructUtil.java ! src/java.base/share/classes/jdk/internal/nicl/UpcallHandler.java From mikael.vidstedt at oracle.com Mon Mar 21 23:35:35 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Mon, 21 Mar 2016 23:35:35 +0000 Subject: hg: panama/panama/jdk: Support bool struct fields Message-ID: <201603212335.u2LNZaSc022680@aojmv0008.oracle.com> Changeset: 1b437aae7842 Author: mikael Date: 2016-03-21 16:35 -0700 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/1b437aae7842 Support bool struct fields ! src/java.base/share/classes/jdk/internal/nicl/StructImplGenerator.java From mikael.vidstedt at oracle.com Mon Mar 21 23:37:34 2016 From: mikael.vidstedt at oracle.com (mikael.vidstedt at oracle.com) Date: Mon, 21 Mar 2016 23:37:34 +0000 Subject: hg: panama/panama/scratch: Add tests and verification of bool type Message-ID: <201603212337.u2LNbY7s023651@aojmv0008.oracle.com> Changeset: d955e976a4b1 Author: mikael Date: 2016-03-21 16:37 -0700 URL: http://hg.openjdk.java.net/panama/panama/scratch/rev/d955e976a4b1 Add tests and verification of bool type ! jdk.internal.nicl.testgen/src/main/java/generator/BasicType.java ! jdk.internal.nicl.testgen/src/main/java/runner/DataGenerator.java ! jdk.internal.nicl.testgen/src/main/java/runner/DataVerifier.java ! jdk.internal.nicl.testgen/src/main/java/runner/StructWalker.java ! jdk.internal.nicl.testgen/src/main/java/runner/TestRunner.java ! jdk.internal.nicl.testgen/src/main/native/verifier.c From henry.jen at oracle.com Tue Mar 22 05:33:38 2016 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 22 Mar 2016 05:33:38 +0000 Subject: hg: panama/panama/jdk: Improve test coverage for Descriptor Message-ID: <201603220533.u2M5XdDI007536@aojmv0008.oracle.com> Changeset: 0f3006d6bc82 Author: henryjen Date: 2016-03-21 22:31 -0700 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/0f3006d6bc82 Improve test coverage for Descriptor ! src/java.base/share/classes/jdk/internal/nicl/types/Descriptor.java ! src/java.base/share/classes/jdk/internal/nicl/types/Pointer.java ! src/java.base/share/classes/jdk/internal/nicl/types/Types.java ! test/java/nicl/types/DescriptorTest.java From henry.jen at oracle.com Tue Mar 22 23:27:30 2016 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 22 Mar 2016 23:27:30 +0000 Subject: hg: panama/panama/jdk: Add layout descriptor Message-ID: <201603222327.u2MNRUx5000649@aojmv0008.oracle.com> Changeset: 977b56d35752 Author: henryjen Date: 2016-03-22 15:37 -0700 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/977b56d35752 Add layout descriptor ! src/java.base/share/classes/java/nicl/metadata/NativeType.java ! src/java.base/share/classes/jdk/internal/nicl/types/Array.java ! src/jdk.dev/share/classes/com/sun/tools/jextract/AsmCodeFactory.java ! src/jdk.dev/share/classes/com/sun/tools/jextract/Utils.java From henry.jen at oracle.com Wed Mar 23 15:06:38 2016 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Wed, 23 Mar 2016 15:06:38 +0000 Subject: hg: panama/panama/jdk: Fix compilation errors introduced by NativeType change Message-ID: <201603231506.u2NF6cp8020451@aojmv0008.oracle.com> Changeset: 8921d183e408 Author: henryjen Date: 2016-03-23 08:06 -0700 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/8921d183e408 Fix compilation errors introduced by NativeType change ! test/com/sun/tools/jextract/Runner.java ! test/com/sun/tools/jextract/Simple.java ! test/java/nicl/System/UnixSystem.java ! test/java/nicl/Upcall/StructUpcall.java ! test/java/nicl/types/DescriptorTest.java From henry.jen at oracle.com Thu Mar 24 18:05:29 2016 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Thu, 24 Mar 2016 18:05:29 +0000 Subject: hg: panama/panama/jdk: Another fix for NativeType Message-ID: <201603241805.u2OI5TsU007198@aojmv0008.oracle.com> Changeset: fad8791433f1 Author: henryjen Date: 2016-03-24 11:05 -0700 URL: http://hg.openjdk.java.net/panama/panama/jdk/rev/fad8791433f1 Another fix for NativeType ! src/demo/share/panama/Panama/stdio.java ! src/demo/share/panama/Panama/stdlib.java ! src/demo/share/panama/Panama/unistd.java From ian.l.graves at intel.com Fri Mar 25 21:45:58 2016 From: ian.l.graves at intel.com (Graves, Ian L) Date: Fri, 25 Mar 2016 21:45:58 +0000 Subject: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation Message-ID: Hello! We've been working with some in-house implementations of the straw man[1] Vector API provided by John and test driving it with some workloads to look for any apparent pain points one could have when using the API to accelerate a common task. One place we started was with simple matrix multiplication of an (let's say two dimensional) array of unboxed floats. We assume the role of a user looking to accelerate a computation given data already in this format. The unaltered straw man API gives us a method to instantiate vectors from an array in the Species of a given Vector with the fromArrayFactory(Float[] f, Integer offset) method. We've been trying to avoid making any significant opinionated changes to the API or specific deviations in an implementation, but some of the issues around this workload warrant some thought (or some help, if somebody knows something I don't [quite likely!]). 1. Little Quibble: It seems as though in order to instantiate a Vector by using a method of the Species, one first needs an instance of a species of that Vector (or a species). Is this the case? This isn't a big deal as we could provide a singleton dummy instance for this or something similar. 2. Not-so-Little Quibble: Assuming that a user wants to leverage this API by starting with primitive types in arrays, the current iteration of the API would seem to require arrays to be boxed because the vector-building methods are all parameterized by element type. For folks coming from primitive arrays, this seems like a non-starter, so maybe I am missing something. What does the path to Vector usage look like if I am coming from primitive arrays? We've war-gamed a couple of possibilities here. I'd love to get the thoughts of the people on this listserv. I'll list them out. 1. Vanilla/Status Quo: We stick with requiring boxed types for now for elegance and simplicity's sake. Construction via parameterized methods will be slower, and perhaps some other non-API method would be better suited to this (static factory methods, etc). 2. Shell Game: Vector -> ConcreteVector takes on a similar flavor and relationship to BaseStream -> IntStream (say). That is, we have element-wise concrete instances of these vectors (FloatVector or FloatVector256/FloatVector8) that have a standardized suite of methods that support primitives and are named consistently across the API like (Int|Double|Long)Stream. This design could incorporate additional interfaces or inherit from abstract classes that contain repeated functionality across element types that we support. 3. Deus ex Machina: JDK 10 or onward introduces a form of specialization[2] powerful enough to let us have our cake and eat it too. While perhaps this isn't something we can bet on to happen concurrent with this API design (or could we?), this might be something we should be planning for. That is, if we know that the API in its current state would be enhanced almost wholesale by the introduction of specialization and/or value types, perhaps that would be a reason enough to leave it how it is and avoid fragmenting it into overly concretized instances. 4. Boxing Elision: Perhaps there's a way we can elide the boxing on these arrays with compiler optimizations, or is there a way already? We are particularly interested in being able to build vectors from arrays because arrays are amenable to gathering[3] and scattering[4] instructions. We can construct lightweight Vector views over arrays of primitives using gathering and scattering (for writes). If the arrays are arrays of boxed types, that makes scattering and gathering a bit more complex as we add a non-uniform layer of indirection to each array index. This is quite useful for workloads like matrix multiplication where it might make sense to stride an array to build a vector. I would love to get thoughts on how we might negotiate this boxing issue, if indeed it is an issue. Thanks! Ian [1] http://cr.openjdk.java.net/~jrose/arrays/vector/Vector.java [2] http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html [3] https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=gather_ps&techs=AVX,AVX2&expand=2798 [4] https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=scatter_ps&techs=AVX_512&expand=2798,4072,2823,2839 From brian.goetz at oracle.com Sat Mar 26 17:43:39 2016 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 26 Mar 2016 13:43:39 -0400 Subject: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation In-Reply-To: References: Message-ID: <56F6CA4B.2080408@oracle.com> For sure, convergence with Valhalla should be part of the goal. For example, we made API choices with VarHandles to not try and make them more type-safe, because (a) it was a low-level API and (b) the ability to make them type-safe at lower cost was coming, and we could wrap VHs later with specialize type-safe wrappers. We may want to consider running this play again, as you allude to in (3). On 3/25/2016 5:45 PM, Graves, Ian L wrote: > Hello! > > We've been working with some in-house implementations of the straw man[1] Vector API provided by John and test driving it with some workloads to look for any apparent pain points one could have when using the API to accelerate a common task. One place we started was with simple matrix multiplication of an (let's say two dimensional) array of unboxed floats. We assume the role of a user looking to accelerate a computation given data already in this format. The unaltered straw man API gives us a method to instantiate vectors from an array in the Species of a given Vector with the fromArrayFactory(Float[] f, Integer offset) method. We've been trying to avoid making any significant opinionated changes to the API or specific deviations in an implementation, but some of the issues around this workload warrant some thought (or some help, if somebody knows something I don't [quite likely!]). > > > 1. Little Quibble: It seems as though in order to instantiate a Vector by using a method of the Species, one first needs an instance of a species of that Vector (or a species). Is this the case? This isn't a big deal as we could provide a singleton dummy instance for this or something similar. > > 2. Not-so-Little Quibble: Assuming that a user wants to leverage this API by starting with primitive types in arrays, the current iteration of the API would seem to require arrays to be boxed because the vector-building methods are all parameterized by element type. For folks coming from primitive arrays, this seems like a non-starter, so maybe I am missing something. What does the path to Vector usage look like if I am coming from primitive arrays? > > We've war-gamed a couple of possibilities here. I'd love to get the thoughts of the people on this listserv. I'll list them out. > > > 1. Vanilla/Status Quo: We stick with requiring boxed types for now for elegance and simplicity's sake. Construction via parameterized methods will be slower, and perhaps some other non-API method would be better suited to this (static factory methods, etc). > > 2. Shell Game: Vector -> ConcreteVector takes on a similar flavor and relationship to BaseStream -> IntStream (say). That is, we have element-wise concrete instances of these vectors (FloatVector or FloatVector256/FloatVector8) that have a standardized suite of methods that support primitives and are named consistently across the API like (Int|Double|Long)Stream. This design could incorporate additional interfaces or inherit from abstract classes that contain repeated functionality across element types that we support. > > 3. Deus ex Machina: JDK 10 or onward introduces a form of specialization[2] powerful enough to let us have our cake and eat it too. While perhaps this isn't something we can bet on to happen concurrent with this API design (or could we?), this might be something we should be planning for. That is, if we know that the API in its current state would be enhanced almost wholesale by the introduction of specialization and/or value types, perhaps that would be a reason enough to leave it how it is and avoid fragmenting it into overly concretized instances. > > 4. Boxing Elision: Perhaps there's a way we can elide the boxing on these arrays with compiler optimizations, or is there a way already? > > We are particularly interested in being able to build vectors from arrays because arrays are amenable to gathering[3] and scattering[4] instructions. We can construct lightweight Vector views over arrays of primitives using gathering and scattering (for writes). If the arrays are arrays of boxed types, that makes scattering and gathering a bit more complex as we add a non-uniform layer of indirection to each array index. This is quite useful for workloads like matrix multiplication where it might make sense to stride an array to build a vector. > > I would love to get thoughts on how we might negotiate this boxing issue, if indeed it is an issue. > > Thanks! > > Ian > > [1] http://cr.openjdk.java.net/~jrose/arrays/vector/Vector.java > [2] http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html > [3] https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=gather_ps&techs=AVX,AVX2&expand=2798 > [4] https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=scatter_ps&techs=AVX_512&expand=2798,4072,2823,2839 > > From panama at zeus.net.au Sat Mar 26 23:45:18 2016 From: panama at zeus.net.au (panama) Date: Sun, 27 Mar 2016 09:45:18 +1000 (AEST) Subject: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation Message-ID: <65df3158e32142a3b19e975a41694b8c@org.tizen.email> One thing I like about Java is it's support for low level api's. Type safety does have security benefits, the sandbox has long since fallen out of favour, which is a shame, the problem I think; there's an over reliance on the security manager and protection domains. ?But it would be nice to have a sandbox which has a limited visible java api, like a subprocess, with resources limits, rather than placing limitations on performance or power. So we could have both unlimited trusted and restricted untrusted environments. 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? Regards, Peter. Sent from my Samsung device. ? ??Include original message ---- Original message ---- From: Brian Goetz Sent: 27/03/2016 03:43:39 am To: Graves, Ian L ; panama-dev at openjdk.java.net Subject: Re: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation For?sure,?convergence?with?Valhalla?should?be?part?of?the?goal.?For? example,?we?made?API?choices?with?VarHandles?to?not?try?and?make?them? more?type-safe,?because?(a)?it?was?a?low-level?API?and?(b)?the?ability? to?make?them?type-safe?at?lower?cost?was?coming,?and?we?could?wrap?VHs? later?with?specialize?type-safe?wrappers.?We?may?want?to?consider? running?this?play?again,?as?you?allude?to?in?(3). On?3/25/2016?5:45?PM,?Graves,?Ian?L?wrote: >?Hello! > >?We've?been?working?with?some?in-house?implementations?of?the?straw?man[1]?Vector?API?provided?by?John?and?test?driving?it?with?some?workloads?to?look?for?any?apparent?pain?points?one?could?have?when?using?the?API?to?accelerate?a?common?task.??One?place?we?started?was?with?simple?matrix?multiplication?of?an?(let's?say?two?dimensional)?array?of?unboxed?floats.??We?assume?the?role?of?a?user?looking?to?accelerate?a?computation?given?data?already?in?this?format.??The?unaltered?straw?man?API?gives?us?a?method?to?instantiate?vectors?from?an?array?in?the?Species?of?a?given?Vector?with?the?fromArrayFactory(Float[]?f,?Integer?offset)?method.??We've?been?trying?to?avoid?making?any?significant?opinionated?changes?to?the?API?or?specific?deviations?in?an?implementation,?but?some?of?the?issues?around?this?workload?warrant?some?thought?(or?some?help,?if?somebody?knows?something?I?don't?[quite?likely!]). > > >?1.???????Little?Quibble:?It?seems?as?though?in?order?to?instantiate?a?Vector?by?using?a?method?of?the?Species,?one?first?needs?an?instance?of?a?species?of?that?Vector?(or?a?species).??Is?this?the?case???This?isn't?a?big?deal?as?we?could?provide?a?singleton?dummy?instance?for?this?or?something?similar. > >?2.???????Not-so-Little?Quibble:?Assuming?that?a?user?wants?to?leverage?this?API?by?starting?with?primitive?types?in?arrays,?the?current?iteration?of?the?API?would?seem?to?require?arrays?to?be?boxed?because?the?vector-building?methods?are?all?parameterized?by?element?type.??For?folks?coming?from?primitive?arrays,?this?seems?like?a?non-starter,?so?maybe?I?am?missing?something.??What?does?the?path?to?Vector?usage?look?like?if?I?am?coming?from?primitive?arrays? > >?We've?war-gamed?a?couple?of?possibilities?here.??I'd?love?to?get?the?thoughts?of?the?people?on?this?listserv.??I'll?list?them?out. > > >?1.???????Vanilla/Status?Quo:??We?stick?with?requiring?boxed?types?for?now?for?elegance?and?simplicity's?sake.??Construction?via?parameterized?methods?will?be?slower,?and?perhaps?some?other?non-API?method?would?be?better?suited?to?this?(static?factory?methods,?etc). > >?2.???????Shell?Game:?Vector?->?ConcreteVector?takes?on?a?similar?flavor?and?relationship?to?BaseStream?->?IntStream?(say).??That?is,?we?have?element-wise?concrete?instances?of?these?vectors?(FloatVector?or?FloatVector256/FloatVector8)?that?have?a?standardized?suite?of?methods?that?support?primitives?and?are?named?consistently?across?the?API?like?(Int|Double|Long)Stream.??This?design?could?incorporate?additional?interfaces?or?inherit?from?abstract?classes?that?contain?repeated?functionality?across?element?types?that?we?support. > >?3.???????Deus?ex?Machina:?JDK?10?or?onward?introduces?a?form?of?specialization[2]?powerful?enough?to?let?us?have?our?cake?and?eat?it?too.??While?perhaps?this?isn't?something?we?can?bet?on?to?happen?concurrent?with?this?API?design?(or?could?we?),?this?might?be?something?we?should?be?planning?for.??That?is,?if?we?know?that?the?API?in?its?current?state?would?be?enhanced?almost?wholesale?by?the?introduction?of?specialization?and/or?value?types,?perhaps?that?would?be?a?reason?enough?to?leave?it?how?it?is?and?avoid?fragmenting?it?into?overly?concretized?instances. > >?4.???????Boxing?Elision:?Perhaps?there's?a?way?we?can?elide?the?boxing?on?these?arrays?with?compiler?optimizations,?or?is?there?a?way?already? > >?We?are?particularly?interested?in?being?able?to?build?vectors?from?arrays?because?arrays?are?amenable?to?gathering[3]?and?scattering[4]?instructions.??We?can?construct?lightweight?Vector?views?over?arrays?of?primitives?using?gathering?and?scattering?(for?writes).??If?the?arrays?are?arrays?of?boxed?types,?that?makes?scattering?and?gathering?a?bit?more?complex?as?we?add?a?non-uniform?layer?of?indirection?to?each?array?index.??This?is?quite?useful?for?workloads?like?matrix?multiplication?where?it?might?make?sense?to?stride?an?array?to?build?a?vector. > >?I?would?love?to?get?thoughts?on?how?we?might?negotiate?this?boxing?issue,?if?indeed?it?is?an?issue. > >?Thanks! > >?Ian > >?[1]?http://cr.openjdk.java.net/~jrose/arrays/vector/Vector.java >?[2]?http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html >?[3]?https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=gather_ps&techs=AVX,AVX2&expand=2798 >?[4]?https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=scatter_ps&techs=AVX_512&expand=2798,4072,2823,2839 > > From john.r.rose at oracle.com Mon Mar 28 19:50:21 2016 From: john.r.rose at oracle.com (John Rose) Date: Mon, 28 Mar 2016 12:50:21 -0700 Subject: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation In-Reply-To: References: Message-ID: <4D73C4DA-DDA1-40AD-ADF7-12B846B7A7F5@oracle.com> On Mar 25, 2016, at 2:45 PM, Graves, Ian L wrote: > > Hello! > > We've been working with some in-house implementations of the straw man[1] Vector API provided by John and test driving it with some workloads to look for any apparent pain points one could have when using the API to accelerate a common task. One place we started was with simple matrix multiplication of an (let's say two dimensional) array of unboxed floats. We assume the role of a user looking to accelerate a computation given data already in this format. The unaltered straw man API gives us a method to instantiate vectors from an array in the Species of a given Vector with the fromArrayFactory(Float[] f, Integer offset) method. We've been trying to avoid making any significant opinionated changes to the API or specific deviations in an implementation, but some of the issues around this workload warrant some thought (or some help, if somebody knows something I don't [quite likely!]). Clearly you are thoroughly engaged with this API; these questions are all very much on-point. For some of this stuff I have an answer already waiting. For some of it I'm still groping around. Here's my take. > 1. Little Quibble: It seems as though in order to instantiate a Vector by using a method of the Species, one first needs an instance of a species of that Vector (or a species). Is this the case? This isn't a big deal as we could provide a singleton dummy instance for this or something similar. I think we need to avoid an explicit user-visible class structure for implementations of Vector, so that implementations can be fully encapsulated. I.e., a user should never say "new FooVectorImpl" to create a vector. The paradigm for vector creation is less like "new ArrayList" and more like "Collections.nCopies". This means we need one or more factory APIs. Putting a factory API into the Vector interface itself is simply a pragmatic move to avoid creating a separate API for vector creation. (It's a "clumping" rather than a "splitting" design move. Both are valid at times, and often matters of taste.) But we may end up with a VectorFactory API if the practicalities move us in that direction. So, yes, a user will first obtain or create a prototypical vector. (Using whatever base-level factory is available: which is TBD.) Then the user will make many vectors that descend from that prototype. It is likely that copying the prototype. How many distinct classes are needed under the hood? Well, vectors are fundamentally distinguished by shape (which determines lane structure) and base type (which determines what's in each lane). That's already a very rich cross-product. Beyond that, we may have specialized HW-influenced vector subtypes, such as gather-vectors or masked-vectors. Higher-level streaming APIs may benefit from vectors whose shape includes a data-dependent lane-count size. In fact, such a high-level vector would be not too different from a view of some or all of the contents of a Stream. (I'm not certain yet where to put a bright line between vectors and streams. We should play with this.) > 2. Not-so-Little Quibble: Assuming that a user wants to leverage this API by starting with primitive types in arrays, the current iteration of the API would seem to require arrays to be boxed because the vector-building methods are all parameterized by element type. We have to make a distinction in an API like this between primitives that occur as scalars, and primitives that occur in memory, as sources or destinations. The latter *must* be packed Fortran-style. The former *may* be boxed, but preferably should be used unboxed. Because of the structure of our generics, there will be complicated tradeoffs, until we get parametric polymorphism over both references and primitives (and value types!) from Project Valhalla. It is as you surmised (below). > For folks coming from primitive arrays, this seems like a non-starter, so maybe I am missing something. What does the path to Vector usage look like if I am coming from primitive arrays? > > We've war-gamed a couple of possibilities here. I'd love to get the thoughts of the people on this listserv. I'll list them out. > > > 1. Vanilla/Status Quo: We stick with requiring boxed types for now for elegance and simplicity's sake. Construction via parameterized methods will be slower, and perhaps some other non-API method would be better suited to this (static factory methods, etc). This will only carry us a little further. You have put your finger on the problem, which is not boxing in general, but specifically memory layout of arrays. In Panama we are also experimenting with notations for specifying non-Java layouts. I think it is quite possible that we will be building Vectors that slice from non-Java arrays, either off-heap, or from the middle of on-heap carrier types like long[], or from a mix of locations, such as ByteBuffers. So the problem will not be solved once we decide on Integer vs. int; we will want to support structural types like complex-number arrays or bit-slice arrays, imported from non-Java APIs. A Vector which carries a handful of such values will need to come from a vector-factory (or shape-factory) which is parameterized by I guess the net of this, for int-vs.-Integer, is that we need to come up with a way for the shape S of a Vector to determine, in a data-dependent way, how the lanes of the vector are to be loaded up from a data source, or stored to a data sink. The mentions of concrete Java array types in the Vector API are therefore simple usage examples, rather than a comprehensive story, of how to get lane data in and out of memory. Those array-based API points are as far as my imagination went, when I was scribbling out the API. There's got to be more. Maybe this is where streams come in? Perhaps we need another complementary pair of APIs for sourcing and sinking data in vector-sized chunks, from a variety of formats. In that case, the existing array-based elements become user conveniences, rather than fundamental cut points. Specifically, I think we may have to decouple occurrences of E[] from E in the Vector API, replacing E[] by a type which expresses the mode of collection: default void intoArray(E[] a, int o) { collect(Collectors.intoArray(a, o); } default R collect(Collector c, int o) { ? } (This assumes that the stream auxiliary type Collector is a good match for vector storage.) > 2. Shell Game: Vector -> ConcreteVector takes on a similar flavor and relationship to BaseStream -> IntStream (say). That is, we have element-wise concrete instances of these vectors (FloatVector or FloatVector256/FloatVector8) that have a standardized suite of methods that support primitives and are named consistently across the API like (Int|Double|Long)Stream. This design could incorporate additional interfaces or inherit from abstract classes that contain repeated functionality across element types that we support. Brian already gave an outline of a good strategy: On Mar 26, 2016, at 10:43 AM, Brian Goetz wrote: > > For sure, convergence with Valhalla should be part of the goal. For example, we made API choices with VarHandles to not try and make them more type-safe, because (a) it was a low-level API and (b) the ability to make them type-safe at lower cost was coming, and we could wrap VHs later with specialize type-safe wrappers. We may want to consider running this play again, as you allude to in (3). I think Brian is over-modest not to emphasize IntStream/Stream as an excellent model for working this problem. I believe that with Valhalla parametric polymorphism, Stream will be a natural, easy-to-adopt replacement for IntStream. > 3. Deus ex Machina: JDK 10 or onward introduces a form of specialization[2] powerful enough to let us have our cake and eat it too. While perhaps this isn't something we can bet on to happen concurrent with this API design (or could we?), this might be something we should be planning for. That is, if we know that the API in its current state would be enhanced almost wholesale by the introduction of specialization and/or value types, perhaps that would be a reason enough to leave it how it is and avoid fragmenting it into overly concretized instances. Yes. Let's steer Vector this way. IntVector now, then Vector later. > 4. Boxing Elision: Perhaps there's a way we can elide the boxing on these arrays with compiler optimizations, or is there a way already? We can't elide boxing on arrays (yet) because Java's array performance model is tightly coupled to the monomorphic (non-varying) format of each array type. In particular, there's no way to abstract over int[] vs. Integer[], because the extra indirections for Integer are intrinsic to the array format. What we *can* abstract over is the boxing of individual values (int vs. Integer). This means that, with a little care, BinaryOperator and IntBinaryOperator can be treated as interchangeable operand formats for HOF methods like Vector.reduce. (Separate problem: We need to give the Vector API some way to "crack" those operands, or to guide the JIT in cracking them, as it organizes its instruction selection.) > We are particularly interested in being able to build vectors from arrays because arrays are amenable to gathering[3] and scattering[4] instructions. We can construct lightweight Vector views over arrays of primitives using gathering and scattering (for writes). If the arrays are arrays of boxed types, that makes scattering and gathering a bit more complex as we add a non-uniform layer of indirection to each array index. This is quite useful for workloads like matrix multiplication where it might make sense to stride an array to build a vector. Yes; see above discussion about vector classes. > I would love to get thoughts on how we might negotiate this boxing issue, if indeed it is an issue. My basic advice: It's time to decouple E[] from E. Isolate E[] into places where bulk data is being sourced or sinked. Either use an interface to abstract the manner for sourcing and sinking (Collector), or use a type parameter shared with Shape. I.e., (as a clumping move) hang the responsibility for sourcing and sinking on the Shape. In that case, the source or sink types could be a type parameter shared between Vector and Shape. Challenge: Do this without complicating Vector too much. Adding IntVector at this time will let you sprinkle the user-friendly API points with "int" and "int[]". ? John > Thanks! > > Ian > > [1] http://cr.openjdk.java.net/~jrose/arrays/vector/Vector.java > [2] http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html > [3] https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=gather_ps&techs=AVX,AVX2&expand=2798 > [4] https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=scatter_ps&techs=AVX_512&expand=2798,4072,2823,2839 > > From john.r.rose at oracle.com Mon Mar 28 19:58:29 2016 From: john.r.rose at oracle.com (John Rose) Date: Mon, 28 Mar 2016 12:58:29 -0700 Subject: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation In-Reply-To: <65df3158e32142a3b19e975a41694b8c@org.tizen.email> References: <65df3158e32142a3b19e975a41694b8c@org.tizen.email> Message-ID: <733A50EA-CE57-44BA-B08D-A0E72AB937EA@oracle.com> On Mar 26, 2016, at 4:45 PM, panama 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 From ian.l.graves at intel.com Wed Mar 30 23:15:13 2016 From: ian.l.graves at intel.com (Graves, Ian L) Date: Wed, 30 Mar 2016 23:15:13 +0000 Subject: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation In-Reply-To: <733A50EA-CE57-44BA-B08D-A0E72AB937EA@oracle.com> References: <65df3158e32142a3b19e975a41694b8c@org.tizen.email> <733A50EA-CE57-44BA-B08D-A0E72AB937EA@oracle.com> Message-ID: 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 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 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 From eliasvasylenko at gmail.com Thu Mar 31 11:36:44 2016 From: eliasvasylenko at gmail.com (elias vasylenko) Date: Thu, 31 Mar 2016 11:36:44 +0000 Subject: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation In-Reply-To: References: <65df3158e32142a3b19e975a41694b8c@org.tizen.email> <733A50EA-CE57-44BA-B08D-A0E72AB937EA@oracle.com> Message-ID: Hi, just a quick question here from someone with 0 knowledge of vector processing trying to follow along out of casual interest... So when you all talk about cracking lambdas, I've been thinking that you mean something like the lambda serialisation trick Jinq uses so they can try to parse streams/lambdas into sensible database queries. Is this somewhat accurate? I don't think I've seen that approach mentioned here before, and perhaps there's a reason for that which I'm not grasping, but it seems like a reasonable fit to me. Lambdas can be compiled into expression trees, and these can be optimised where possible into vector instructions, right? Requiring lambdas to be serializable to be able to optimise is a little restrictive, but I can't see that being much of a problem in this case. On Thu, 31 Mar 2016 at 00:15 Graves, Ian L wrote: > 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 > 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 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 > From john.r.rose at oracle.com Thu Mar 31 22:32:43 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 31 Mar 2016 15:32:43 -0700 Subject: Vector API "Straw Man" Boxed/Unboxed Vector Instantiation In-Reply-To: References: <65df3158e32142a3b19e975a41694b8c@org.tizen.email> <733A50EA-CE57-44BA-B08D-A0E72AB937EA@oracle.com> Message-ID: <58ED58F9-3A88-4A39-A9EB-741B82476191@oracle.com> On Mar 31, 2016, at 4:36 AM, elias vasylenko wrote: > > Hi, just a quick question here from someone with 0 knowledge of vector processing trying to follow along out of casual interest... So when you all talk about cracking lambdas, I've been thinking that you mean something like the lambda serialisation trick Jinq uses so they can try to parse streams/lambdas into sensible database queries. Is this somewhat accurate? Yes, somewhat. Jinq is built on a shaky foundation, since the JVM and classfile format was not designed to allow either method bytecodes or expression trees to be recovered by library code. One option we are talking about (not the only option) is amending the foundation, by allowing class files to store enough data to recover expression trees, and then provide an API for getting that. The serialization trick is just that: a trick, to get access to the bytecode behavior of the lambda. We have lower-level APIs for getting the same information out of the JVM "in-place" without serializing, since of course the JIT needs that information. We are up-leveling that access to Java in the JVMCI, derived from the Graal interface. BTW, I believe we could do the equivalent of expression trees as an add-on to bytecodes, rather than a separate data structure, but that's a tricky discussion. The idea is to condition the bytecodes with new structural constraints so that a Jinq-like decoding step is guaranteed to "play back" the original expression (as compiled, with non-semantic details erased). ? John