From mauro.tortonesi at unife.it Wed Jun 1 11:31:59 2016 From: mauro.tortonesi at unife.it (Tortonesi Mauro) Date: Wed, 1 Jun 2016 13:31:59 +0200 Subject: cannot compile graal with gcc 6.1 on 64bit linux and jdk 8u92 In-Reply-To: References: Message-ID: 2016-05-30 21:15 GMT+02:00 Doug Simon : > Hi Mauro, > > As previously mentioned[1], C++11 is not (yet) supported by HotSpot. > > The good news is that we?re very close to having prebuilt, JVMCI enabled JDK8 binaries ready. There are remaining steps in terms of finding the appropriate location for hosting the binaries but I expect that to be resolved soon. By mid-June, I expect the binaries will be available. > > -Doug > > [1] http://mail.openjdk.java.net/pipermail/graal-dev/2016-May/004359.html Dear Doug, thank you very much for your kind reply. There must have been a misunderstanding here, so please let me clarify. First of all, let me state what is my objective here: I would like to build Graal on top of JDK 8 (version 72) on my 64-bit Arch Linux system. (Ultimately, I am interested in finding out if JRuby+Truffle can bring any significant speedup to my JRuby-based scientific projects: https://github.com/mtortonesi/symian and https://github.com/mtortonesi/sisfc.) >From what I understand, the problem I am having is caused by the fact that the compiler on my system is GCC version 6.1. In fact, while GCC adopted the C++98 standard as default until version 6.0 (included): https://gcc.gnu.org/projects/cxx-status.html#cxx98 it switched to the C++14 standard as default from version 6.1: https://gcc.gnu.org/projects/cxx-status.html#cxx14 I had well understood from your previous e-mail (and my previous compilation attempts) that Graal won't compile using C++11. However, I gave it another try because of: 1) Chris Seaton's implicit invitation not to give up on a Twitter conversation: https://twitter.com/ChrisGSeaton/status/736544090456723456 2) the assumption that instructing mx to use GCC in C++98 mode was not going to be so difficult (and the hope that some of Graal's developers were already using GCC version 6.1 in their day-to-day work); 3) the fact that finding out how to compile Graal with GCC 6.1 would have also been valuable to other users, thus making it an issue deserving further investigation. Elaborating on the second point, I assumed it was possible to compile Graal with GCC 6.1 by simply using a command like: CXXFLAGS="-std=c++98" mx --vm server build However, when I grepped the mx sources for either "CFLAGS", "CC", or similar words I couldn't find anything. So I am guessing that mx does not allow to easily specify compilation parameters like make (and most of the other building tools that I know of) do. Before giving up on any further compilation attempt and waiting for JVMCI enabled JDK8 binaries, could I please ask you if there is an easy way to instruct mx to use the "-std=c++98" flag when calling GCC? Thank you very much again. Ciao, Mauro -- Mauro Tortonesi, Ph.D. Assistant Professor Distributed Systems Research Group Engineering Department University of Ferrara From christian.humer at gmail.com Wed Jun 1 11:49:54 2016 From: christian.humer at gmail.com (Christian Humer) Date: Wed, 01 Jun 2016 11:49:54 +0000 Subject: cannot compile graal with gcc 6.1 on 64bit linux and jdk 8u92 In-Reply-To: References: Message-ID: Hi Mauro, If you goal is to run ruby applications, then it might just be simpler to use GraalVM [1]. It is a JVMCI JDK 8 with Graal, JS, R and Ruby integrated. The latest release is about a month old and it comes with everything prebuilt to be used on a 64 bit Linux. You can find an executable to execute ruby programs with JRuby+Truffle in GraalVM/bin/ruby or for a shell GraalVM/bin/irb. If you download the development kit, there are also some examples in the GraalVM/examples folder. [1] http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html Cheers, Christian Humer On 01.06.2016 13:31:59, "Tortonesi Mauro" wrote: >2016-05-30 21:15 GMT+02:00 Doug Simon : >> Hi Mauro, >> >> As previously mentioned[1], C++11 is not (yet) supported by HotSpot. >> >> The good news is that we?re very close to having prebuilt, JVMCI >>enabled JDK8 binaries ready. There are remaining steps in terms of >>finding the appropriate location for hosting the binaries but I expect >>that to be resolved soon. By mid-June, I expect the binaries will be >>available. >> >> -Doug >> >> [1] >>http://mail.openjdk.java.net/pipermail/graal-dev/2016-May/004359.html > >Dear Doug, > >thank you very much for your kind reply. There must have been a >misunderstanding here, so please let me clarify. > >First of all, let me state what is my objective here: I would like to >build Graal on top of JDK 8 (version 72) on my 64-bit Arch Linux >system. (Ultimately, I am interested in finding out if JRuby+Truffle >can bring any significant speedup to my JRuby-based scientific >projects: https://github.com/mtortonesi/symian and >https://github.com/mtortonesi/sisfc.) > >From what I understand, the problem I am having is caused by the fact >that the compiler on my system is GCC version 6.1. In fact, while GCC >adopted the C++98 standard as default until version 6.0 (included): > >https://gcc.gnu.org/projects/cxx-status.html#cxx98 > >it switched to the C++14 standard as default from version 6.1: > >https://gcc.gnu.org/projects/cxx-status.html#cxx14 > >I had well understood from your previous e-mail (and my previous >compilation attempts) that Graal won't compile using C++11. However, I >gave it another try because of: > >1) Chris Seaton's implicit invitation not to give up on a Twitter >conversation: > >https://twitter.com/ChrisGSeaton/status/736544090456723456 > >2) the assumption that instructing mx to use GCC in C++98 mode was not >going to be so difficult (and the hope that some of Graal's developers >were already using GCC version 6.1 in their day-to-day work); > >3) the fact that finding out how to compile Graal with GCC 6.1 would >have also been valuable to other users, thus making it an issue >deserving further investigation. > >Elaborating on the second point, I assumed it was possible to compile >Graal with GCC 6.1 by simply using a command like: > >CXXFLAGS="-std=c++98" mx --vm server build > >However, when I grepped the mx sources for either "CFLAGS", "CC", or >similar words I couldn't find anything. So I am guessing that mx does >not allow to easily specify compilation parameters like make (and most >of the other building tools that I know of) do. > >Before giving up on any further compilation attempt and waiting for >JVMCI enabled JDK8 binaries, could I please ask you if there is an >easy way to instruct mx to use the "-std=c++98" flag when calling GCC? > >Thank you very much again. > > >Ciao, >Mauro > >-- >Mauro Tortonesi, Ph.D. > >Assistant Professor >Distributed Systems Research Group >Engineering Department >University of Ferrara From roland.schatz at oracle.com Wed Jun 1 11:52:17 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Wed, 1 Jun 2016 13:52:17 +0200 Subject: cannot compile graal with gcc 6.1 on 64bit linux and jdk 8u92 In-Reply-To: References: Message-ID: <2cd9be63-fa6f-1508-fd68-5c995fdaac5c@oracle.com> On 06/01/2016 01:31 PM, Tortonesi Mauro wrote: > 3) the fact that finding out how to compile Graal with GCC 6.1 would > have also been valuable to other users, thus making it an issue > deserving further investigation. > > Elaborating on the second point, I assumed it was possible to compile > Graal with GCC 6.1 by simply using a command like: > > CXXFLAGS="-std=c++98" mx --vm server build Oh... I wasn't aware that it's that simple ;) In hotspot, it's CFLAGS, not CXXFLAGS. This command works on my system (ArchLinux with gcc 6.1): > CFLAGS="-std=c++98" mx build > > However, when I grepped the mx sources for either "CFLAGS", "CC", or > similar words I couldn't find anything. So I am guessing that mx does > not allow to easily specify compilation parameters like make (and most > of the other building tools that I know of) do. > > Before giving up on any further compilation attempt and waiting for > JVMCI enabled JDK8 binaries, could I please ask you if there is an > easy way to instruct mx to use the "-std=c++98" flag when calling GCC? mx is not doing the c++ compilation itself, it's just calling make. That's why you don't see any references to the C specific environment variables in the mx source code, all of that is in the hotspot makefiles. - Roland From bahram.yarahmadi at gmail.com Sun Jun 5 10:13:20 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Sun, 5 Jun 2016 14:43:20 +0430 Subject: Problem with IGV In-Reply-To: References: <760508C2-8141-453C-B4C4-5C9286F646E7@oracle.com> <08AEE623-DC19-4652-BFBE-DB2F9891CE54@oracle.com> <0DA38775-0700-4BF0-B13E-E4667EB21B25@oracle.com> <21052C7B-3BCD-4C33-AED2-E10ECC1C26E4@oracle.com> Message-ID: Hello again guys, I have another problem with IGV When I want to run IGV for the first time ,I get this error /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/build.xml:7: The following error occurred while executing this line: /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/build-impl.xml:41: The following error occurred while executing this line: /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/platform.xml:28: taskdef class org.netbeans.nbbuild.AutoUpdate cannot be found using the classloader AntClassLoader[/tmp/tasks.jar] and task.jar is located in my tmp directory What should I do? Thanks Regards On Tue, Mar 15, 2016 at 3:36 PM, Bahram Yarahmadi < bahram.yarahmadi at gmail.com> wrote: > Thanks ,You solved my problem > > Regards > > Bahram > > On Mon, Mar 14, 2016 at 7:37 PM, Doug Simon wrote: > >> Since IGV is launched with ant, you can specify ant proxies[1] via the >> ANT_OPTS environment variable. For example: >> >> $ export ANT_OPTS="-Dhttp.proxyHost=www-proxy.company.com >> -Dhttp.proxyPort=80? >> $ mx igv >> >> -Doug >> >> [1] https://ant.apache.org/manual/proxy.html >> >> > On 14 Mar 2016, at 15:44, Bahram Yarahmadi >> wrote: >> > >> > Thanks Doug, >> > You helped me a lot >> > >> > >> > Regards , >> > >> > >> > On Mon, Mar 14, 2016 at 6:00 PM, Bahram Yarahmadi < >> bahram.yarahmadi at gmail.com> wrote: >> > I'm in iran and the url is not accesable for me ,But I can download the >> file with some proxy setting in my web brower !! >> > >> > >> > On Mon, Mar 14, 2016 at 5:35 PM, Doug Simon >> wrote: >> > Might be a network issue on your end as I can download >> http://updates.netbeans.org/netbeans/updates/7.4/uc/final/distribution/catalog.xml.gz >> fine. Can you download it in a browser? >> > >> > >> > > On 14 Mar 2016, at 14:30, Bahram Yarahmadi < >> bahram.yarahmadi at gmail.com> wrote: >> > > >> > > Sorry Doug,Please accept my apology,The file was hidden and I didn't >> know >> > > And the content of the file : >> > > download: >> > > [mkdir] Created dir: >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbplatform/harness >> > > [echo] Downloading clusters ide|platform >> > > [get] Getting: >> http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/netbeans/harness/tasks.jar >> > > [get] To: /tmp/tasks.jar >> > > [get] local file date : Mon Mar 14 09:12:41 IRST 2016 >> > > [get] Not modified - so not downloaded >> > > [autoupdate] Downloading >> http://updates.netbeans.org/netbeans/updates/7.4/uc/final/distribution/catalog.xml.gz >> > > >> > > BUILD FAILED >> > > >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/build.xml:7: >> The following error occurred while executing this line: >> > > >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/build-impl.xml:41: >> The following error occurred while executing this line: >> > > >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/platform.xml:29: >> Server returned HTTP response code: 403 for URL: >> http://updates.netbeans.org/netbeans/updates/7.4/uc/final/distribution/catalog.xml.gz >> > > >> > > Total time: 11 seconds >> > > >> > > On Mon, Mar 14, 2016 at 4:46 PM, Doug Simon >> wrote: >> > > >> > > > On 14 Mar 2016, at 14:08, Bahram Yarahmadi < >> bahram.yarahmadi at gmail.com> wrote: >> > > > >> > > > There is no such file .ideal_graph_visualizer.log. >> > > >> > > This file is in the jvmci suite directory which I?m guessing is >> ../jvmci/.ideal_graph_visualizer.log or >> ../graal-jvmci-8/.ideal_graph_visualizer.log for you (assuming you are in >> the graal-core/ directory). >> > > >> > > -Doug >> > > >> > >> > >> > >> >> > From bahram.yarahmadi at gmail.com Sun Jun 5 10:54:51 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Sun, 5 Jun 2016 15:24:51 +0430 Subject: Graal JVMCI Problem Message-ID: Hello guys, I made a very simple program ,which is : mport java.lang.reflect.Method; import com.oracle.graal.api.test.Graal; import com.oracle.graal.code.CompilationResult; import com.oracle.graal.compiler.GraalCompiler; import com.oracle.graal.compiler.target.Backend; import com.oracle.graal.lir.asm.CompilationResultBuilderFactory; import com.oracle.graal.lir.phases.LIRSuites; import com.oracle.graal.nodes.StructuredGraph; import com.oracle.graal.nodes.StructuredGraph.AllowAssumptions; import com.oracle.graal.phases.OptimisticOptimizations; import com.oracle.graal.phases.PhaseSuite; import com.oracle.graal.phases.tiers.HighTierContext; import com.oracle.graal.phases.tiers.Suites; import com.oracle.graal.phases.util.Providers; import com.oracle.graal.runtime.RuntimeProvider; import jdk.vm.ci.code.CodeCacheProvider; import jdk.vm.ci.code.CompiledCode; import jdk.vm.ci.code.InstalledCode; import jdk.vm.ci.meta.MetaAccessProvider; import jdk.vm.ci.meta.ProfilingInfo; import jdk.vm.ci.meta.ResolvedJavaMethod; public class BahramMain { public static RuntimeProvider runetimeProvider=Graal.getRequiredCapability(RuntimeProvider.class); public static Backend backend=runetimeProvider.getHostBackend(); public static MetaAccessProvider metaAccess=backend.getMetaAccess(); public static CodeCacheProvider codeCache=backend.getCodeCache(); public static Providers providers=backend.getProviders(); public static int addTwoIntegers(int x,int y){ if (x > y){ return x + y; } return x - y; } public static void main(String []args){ ResolvedJavaMethod method=findMethod(BahramMain.class, "addTwoIntegers"); StructuredGraph graph = new StructuredGraph(method, AllowAssumptions.YES); /* * The phases used to build the graph. Usually this is just the GraphBuilderPhase. If * the graph already contains nodes, it is ignored. */ PhaseSuite graphBuilderSuite = backend.getSuites().getDefaultGraphBuilderSuite(); /* * The optimization phases that are applied to the graph. This is the main configuration * point for Graal. Add or remove phases to customize your compilation. */ Suites suites = backend.getSuites().getDefaultSuites(); /* * The low-level phases that are applied to the low-level representation. */ LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); /* * We want Graal to perform all speculative optimistic optimizations, using the * profiling information that comes with the method (collected by the interpreter) for * speculation. */ OptimisticOptimizations optimisticOpts = OptimisticOptimizations.ALL; ProfilingInfo profilingInfo = graph.getProfilingInfo(method); /* The default class and configuration for compilation results. */ CompilationResult compilationResult = new CompilationResult(); CompilationResultBuilderFactory factory = CompilationResultBuilderFactory.Default; /* Invoke the whole Graal compilation pipeline. */ GraalCompiler.compileGraph(graph, method, providers, backend, graphBuilderSuite, optimisticOpts, profilingInfo, suites, lirSuites, compilationResult, factory); /* * Install the compilation result into the VM, i.e., copy the byte[] array that contains * the machine code into an actual executable memory location. */ CompiledCode compiledCode = backend.createCompiledCode(method, compilationResult); InstalledCode installedCode = codeCache.addCode(method, compiledCode, null, null); System.out.println("The number Of methods in the graph is "+ graph.getNodeCount()); } public static ResolvedJavaMethod findMethod(Class declaringClass, String name) { Method reflectionMethod = null; for (Method m : declaringClass.getDeclaredMethods()) { if (m.getName().equals(name)) { assert reflectionMethod == null : "More than one method with name " + name + " in class " + declaringClass.getName(); reflectionMethod = m; } } assert reflectionMethod != null : "No method with name " + name + " in class " + declaringClass.getName(); return metaAccess.lookupJavaMethod(reflectionMethod); } } but when I want to run it on eclipse with out unittest I get this error : Exception in thread "main" java.lang.ExceptionInInitializerError at BahramMain.(BahramMain.java:26) Caused by: java.lang.UnsupportedOperationException: The VM does not support the JVMCI API. Currently used Java home directory is /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. Currently used VM configuration is: OpenJDK 64-Bit Server VM at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50) at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44) at com.oracle.graal.api.test.Graal.(Graal.java:40) ... 1 more From bahram.yarahmadi at gmail.com Sun Jun 5 10:56:06 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Sun, 5 Jun 2016 15:26:06 +0430 Subject: Graal JVMCI Problem In-Reply-To: References: Message-ID: What should I do ? Thanks , Regards On Sun, Jun 5, 2016 at 3:24 PM, Bahram Yarahmadi wrote: > Hello guys, > I made a very simple program ,which is : > > mport java.lang.reflect.Method; > > import com.oracle.graal.api.test.Graal; > import com.oracle.graal.code.CompilationResult; > import com.oracle.graal.compiler.GraalCompiler; > import com.oracle.graal.compiler.target.Backend; > import com.oracle.graal.lir.asm.CompilationResultBuilderFactory; > import com.oracle.graal.lir.phases.LIRSuites; > import com.oracle.graal.nodes.StructuredGraph; > import com.oracle.graal.nodes.StructuredGraph.AllowAssumptions; > import com.oracle.graal.phases.OptimisticOptimizations; > import com.oracle.graal.phases.PhaseSuite; > import com.oracle.graal.phases.tiers.HighTierContext; > import com.oracle.graal.phases.tiers.Suites; > import com.oracle.graal.phases.util.Providers; > import com.oracle.graal.runtime.RuntimeProvider; > > import jdk.vm.ci.code.CodeCacheProvider; > import jdk.vm.ci.code.CompiledCode; > import jdk.vm.ci.code.InstalledCode; > import jdk.vm.ci.meta.MetaAccessProvider; > import jdk.vm.ci.meta.ProfilingInfo; > import jdk.vm.ci.meta.ResolvedJavaMethod; > > public class BahramMain { > public static RuntimeProvider > runetimeProvider=Graal.getRequiredCapability(RuntimeProvider.class); > public static Backend backend=runetimeProvider.getHostBackend(); > public static MetaAccessProvider metaAccess=backend.getMetaAccess(); > public static CodeCacheProvider codeCache=backend.getCodeCache(); > public static Providers providers=backend.getProviders(); > public static int addTwoIntegers(int x,int y){ > if (x > y){ > return x + y; > } > return x - y; > } > public static void main(String []args){ > ResolvedJavaMethod method=findMethod(BahramMain.class, "addTwoIntegers"); > StructuredGraph graph = new StructuredGraph(method, AllowAssumptions.YES); > > /* > * The phases used to build the graph. Usually this is just the > GraphBuilderPhase. If > * the graph already contains nodes, it is ignored. > */ > PhaseSuite graphBuilderSuite = > backend.getSuites().getDefaultGraphBuilderSuite(); > > /* > * The optimization phases that are applied to the graph. This is > the main configuration > * point for Graal. Add or remove phases to customize your > compilation. > */ > Suites suites = backend.getSuites().getDefaultSuites(); > > /* > * The low-level phases that are applied to the low-level > representation. > */ > LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); > > /* > * We want Graal to perform all speculative optimistic > optimizations, using the > * profiling information that comes with the method (collected by > the interpreter) for > * speculation. > */ > OptimisticOptimizations optimisticOpts = > OptimisticOptimizations.ALL; > ProfilingInfo profilingInfo = graph.getProfilingInfo(method); > > /* The default class and configuration for compilation results. */ > CompilationResult compilationResult = new CompilationResult(); > CompilationResultBuilderFactory factory = > CompilationResultBuilderFactory.Default; > > /* Invoke the whole Graal compilation pipeline. */ > GraalCompiler.compileGraph(graph, method, providers, backend, > graphBuilderSuite, optimisticOpts, profilingInfo, suites, lirSuites, > compilationResult, factory); > > /* > * Install the compilation result into the VM, i.e., copy the > byte[] array that contains > * the machine code into an actual executable memory location. > */ > CompiledCode compiledCode = backend.createCompiledCode(method, > compilationResult); > InstalledCode installedCode = codeCache.addCode(method, > compiledCode, null, null); > System.out.println("The number Of methods in the graph is "+ > graph.getNodeCount()); > > } > public static ResolvedJavaMethod findMethod(Class declaringClass, > String name) { > Method reflectionMethod = null; > for (Method m : declaringClass.getDeclaredMethods()) { > if (m.getName().equals(name)) { > assert reflectionMethod == null : "More than one method > with name " + name + " in class " + declaringClass.getName(); > reflectionMethod = m; > } > } > assert reflectionMethod != null : "No method with name " + name + " > in class " + declaringClass.getName(); > return metaAccess.lookupJavaMethod(reflectionMethod); > } > > } > but when I want to run it on eclipse with out unittest I get this error : > Exception in thread "main" java.lang.ExceptionInInitializerError > at BahramMain.(BahramMain.java:26) > Caused by: java.lang.UnsupportedOperationException: The VM does not > support the JVMCI API. > Currently used Java home directory is > /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. > Currently used VM configuration is: OpenJDK 64-Bit Server VM > at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50) > at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44) > at com.oracle.graal.api.test.Graal.(Graal.java:40) > ... 1 more > > From forax at univ-mlv.fr Sun Jun 5 14:35:28 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 5 Jun 2016 16:35:28 +0200 (CEST) Subject: Graal JVMCI Problem In-Reply-To: References: Message-ID: <670103238.659316.1465137328693.JavaMail.zimbra@u-pem.fr> I may be wrong but i think that the JVMCI API was introduced in JDK 9, so i think you need a JDK 9. cheers, R?mi ----- Mail original ----- > De: "Bahram Yarahmadi" > ?: graal-dev at openjdk.java.net > Envoy?: Dimanche 5 Juin 2016 12:56:06 > Objet: Re: Graal JVMCI Problem > > What should I do ? > > Thanks , > > Regards > > On Sun, Jun 5, 2016 at 3:24 PM, Bahram Yarahmadi > wrote: > > > Hello guys, > > I made a very simple program ,which is : > > > > mport java.lang.reflect.Method; > > > > import com.oracle.graal.api.test.Graal; > > import com.oracle.graal.code.CompilationResult; > > import com.oracle.graal.compiler.GraalCompiler; > > import com.oracle.graal.compiler.target.Backend; > > import com.oracle.graal.lir.asm.CompilationResultBuilderFactory; > > import com.oracle.graal.lir.phases.LIRSuites; > > import com.oracle.graal.nodes.StructuredGraph; > > import com.oracle.graal.nodes.StructuredGraph.AllowAssumptions; > > import com.oracle.graal.phases.OptimisticOptimizations; > > import com.oracle.graal.phases.PhaseSuite; > > import com.oracle.graal.phases.tiers.HighTierContext; > > import com.oracle.graal.phases.tiers.Suites; > > import com.oracle.graal.phases.util.Providers; > > import com.oracle.graal.runtime.RuntimeProvider; > > > > import jdk.vm.ci.code.CodeCacheProvider; > > import jdk.vm.ci.code.CompiledCode; > > import jdk.vm.ci.code.InstalledCode; > > import jdk.vm.ci.meta.MetaAccessProvider; > > import jdk.vm.ci.meta.ProfilingInfo; > > import jdk.vm.ci.meta.ResolvedJavaMethod; > > > > public class BahramMain { > > public static RuntimeProvider > > runetimeProvider=Graal.getRequiredCapability(RuntimeProvider.class); > > public static Backend backend=runetimeProvider.getHostBackend(); > > public static MetaAccessProvider metaAccess=backend.getMetaAccess(); > > public static CodeCacheProvider codeCache=backend.getCodeCache(); > > public static Providers providers=backend.getProviders(); > > public static int addTwoIntegers(int x,int y){ > > if (x > y){ > > return x + y; > > } > > return x - y; > > } > > public static void main(String []args){ > > ResolvedJavaMethod method=findMethod(BahramMain.class, "addTwoIntegers"); > > StructuredGraph graph = new StructuredGraph(method, AllowAssumptions.YES); > > > > /* > > * The phases used to build the graph. Usually this is just the > > GraphBuilderPhase. If > > * the graph already contains nodes, it is ignored. > > */ > > PhaseSuite graphBuilderSuite = > > backend.getSuites().getDefaultGraphBuilderSuite(); > > > > /* > > * The optimization phases that are applied to the graph. This is > > the main configuration > > * point for Graal. Add or remove phases to customize your > > compilation. > > */ > > Suites suites = backend.getSuites().getDefaultSuites(); > > > > /* > > * The low-level phases that are applied to the low-level > > representation. > > */ > > LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); > > > > /* > > * We want Graal to perform all speculative optimistic > > optimizations, using the > > * profiling information that comes with the method (collected by > > the interpreter) for > > * speculation. > > */ > > OptimisticOptimizations optimisticOpts = > > OptimisticOptimizations.ALL; > > ProfilingInfo profilingInfo = graph.getProfilingInfo(method); > > > > /* The default class and configuration for compilation results. */ > > CompilationResult compilationResult = new CompilationResult(); > > CompilationResultBuilderFactory factory = > > CompilationResultBuilderFactory.Default; > > > > /* Invoke the whole Graal compilation pipeline. */ > > GraalCompiler.compileGraph(graph, method, providers, backend, > > graphBuilderSuite, optimisticOpts, profilingInfo, suites, lirSuites, > > compilationResult, factory); > > > > /* > > * Install the compilation result into the VM, i.e., copy the > > byte[] array that contains > > * the machine code into an actual executable memory location. > > */ > > CompiledCode compiledCode = backend.createCompiledCode(method, > > compilationResult); > > InstalledCode installedCode = codeCache.addCode(method, > > compiledCode, null, null); > > System.out.println("The number Of methods in the graph is "+ > > graph.getNodeCount()); > > > > } > > public static ResolvedJavaMethod findMethod(Class declaringClass, > > String name) { > > Method reflectionMethod = null; > > for (Method m : declaringClass.getDeclaredMethods()) { > > if (m.getName().equals(name)) { > > assert reflectionMethod == null : "More than one method > > with name " + name + " in class " + declaringClass.getName(); > > reflectionMethod = m; > > } > > } > > assert reflectionMethod != null : "No method with name " + name + " > > in class " + declaringClass.getName(); > > return metaAccess.lookupJavaMethod(reflectionMethod); > > } > > > > } > > but when I want to run it on eclipse with out unittest I get this error : > > Exception in thread "main" java.lang.ExceptionInInitializerError > > at BahramMain.(BahramMain.java:26) > > Caused by: java.lang.UnsupportedOperationException: The VM does not > > support the JVMCI API. > > Currently used Java home directory is > > /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. > > Currently used VM configuration is: OpenJDK 64-Bit Server VM > > at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50) > > at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44) > > at com.oracle.graal.api.test.Graal.(Graal.java:40) > > ... 1 more > > > > > From java at stefan-marr.de Sun Jun 5 15:03:03 2016 From: java at stefan-marr.de (Stefan Marr) Date: Sun, 5 Jun 2016 17:03:03 +0200 Subject: Graal JVMCI Problem In-Reply-To: References: Message-ID: Hi: Are you building Graal from the latest graal-core code? You?ll likely need extra arguments to the VM: -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -d64 -Djvmci.Compiler=graal And possibly: -XX:+UseJVMCICompiler depending on whether all Java code should be compiled with it. To know what the correct way to invoke Java is, you can check mx. Something like `mx -Mjit -v vm -version` should print out the correct way of invoking the JVM with Graal enabled. Remi, the code at https://github.com/graalvm/graal-core build a Hotspot for JDK 8 with JVMCI. Best regards Stefan > On 05 Jun 2016, at 12:54, Bahram Yarahmadi wrote: > > Hello guys, > I made a very simple program ,which is : > > mport java.lang.reflect.Method; > > import com.oracle.graal.api.test.Graal; > import com.oracle.graal.code.CompilationResult; > import com.oracle.graal.compiler.GraalCompiler; > import com.oracle.graal.compiler.target.Backend; > import com.oracle.graal.lir.asm.CompilationResultBuilderFactory; > import com.oracle.graal.lir.phases.LIRSuites; > import com.oracle.graal.nodes.StructuredGraph; > import com.oracle.graal.nodes.StructuredGraph.AllowAssumptions; > import com.oracle.graal.phases.OptimisticOptimizations; > import com.oracle.graal.phases.PhaseSuite; > import com.oracle.graal.phases.tiers.HighTierContext; > import com.oracle.graal.phases.tiers.Suites; > import com.oracle.graal.phases.util.Providers; > import com.oracle.graal.runtime.RuntimeProvider; > > import jdk.vm.ci.code.CodeCacheProvider; > import jdk.vm.ci.code.CompiledCode; > import jdk.vm.ci.code.InstalledCode; > import jdk.vm.ci.meta.MetaAccessProvider; > import jdk.vm.ci.meta.ProfilingInfo; > import jdk.vm.ci.meta.ResolvedJavaMethod; > > public class BahramMain { > public static RuntimeProvider > runetimeProvider=Graal.getRequiredCapability(RuntimeProvider.class); > public static Backend backend=runetimeProvider.getHostBackend(); > public static MetaAccessProvider metaAccess=backend.getMetaAccess(); > public static CodeCacheProvider codeCache=backend.getCodeCache(); > public static Providers providers=backend.getProviders(); > public static int addTwoIntegers(int x,int y){ > if (x > y){ > return x + y; > } > return x - y; > } > public static void main(String []args){ > ResolvedJavaMethod method=findMethod(BahramMain.class, "addTwoIntegers"); > StructuredGraph graph = new StructuredGraph(method, AllowAssumptions.YES); > > /* > * The phases used to build the graph. Usually this is just the > GraphBuilderPhase. If > * the graph already contains nodes, it is ignored. > */ > PhaseSuite graphBuilderSuite = > backend.getSuites().getDefaultGraphBuilderSuite(); > > /* > * The optimization phases that are applied to the graph. This is > the main configuration > * point for Graal. Add or remove phases to customize your > compilation. > */ > Suites suites = backend.getSuites().getDefaultSuites(); > > /* > * The low-level phases that are applied to the low-level > representation. > */ > LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); > > /* > * We want Graal to perform all speculative optimistic > optimizations, using the > * profiling information that comes with the method (collected by > the interpreter) for > * speculation. > */ > OptimisticOptimizations optimisticOpts = > OptimisticOptimizations.ALL; > ProfilingInfo profilingInfo = graph.getProfilingInfo(method); > > /* The default class and configuration for compilation results. */ > CompilationResult compilationResult = new CompilationResult(); > CompilationResultBuilderFactory factory = > CompilationResultBuilderFactory.Default; > > /* Invoke the whole Graal compilation pipeline. */ > GraalCompiler.compileGraph(graph, method, providers, backend, > graphBuilderSuite, optimisticOpts, profilingInfo, suites, lirSuites, > compilationResult, factory); > > /* > * Install the compilation result into the VM, i.e., copy the > byte[] array that contains > * the machine code into an actual executable memory location. > */ > CompiledCode compiledCode = backend.createCompiledCode(method, > compilationResult); > InstalledCode installedCode = codeCache.addCode(method, > compiledCode, null, null); > System.out.println("The number Of methods in the graph is "+ > graph.getNodeCount()); > > } > public static ResolvedJavaMethod findMethod(Class declaringClass, String > name) { > Method reflectionMethod = null; > for (Method m : declaringClass.getDeclaredMethods()) { > if (m.getName().equals(name)) { > assert reflectionMethod == null : "More than one method with > name " + name + " in class " + declaringClass.getName(); > reflectionMethod = m; > } > } > assert reflectionMethod != null : "No method with name " + name + " > in class " + declaringClass.getName(); > return metaAccess.lookupJavaMethod(reflectionMethod); > } > > } > but when I want to run it on eclipse with out unittest I get this error : > Exception in thread "main" java.lang.ExceptionInInitializerError > at BahramMain.(BahramMain.java:26) > Caused by: java.lang.UnsupportedOperationException: The VM does not support > the JVMCI API. > Currently used Java home directory is > /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. > Currently used VM configuration is: OpenJDK 64-Bit Server VM > at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50) > at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44) > at com.oracle.graal.api.test.Graal.(Graal.java:40) > ... 1 more -- Stefan Marr Johannes Kepler Universit?t Linz http://stefan-marr.de/research/ From Jerven.Bolleman at sib.swiss Mon Jun 6 07:18:25 2016 From: Jerven.Bolleman at sib.swiss (Jerven Tjalling Bolleman) Date: Mon, 06 Jun 2016 09:18:25 +0200 Subject: Experimenting with running a java process on graalvm-0.11-dev-dk Message-ID: Dear Graal developers, Last week I started experimenting with running a largish Java application on graal to see the difference with standard hotspot. There are two pieces of sad news I have to report. The first is there are exceptions occurring in the code that are only triggered when running graal. Specifically, in the Lucene 4.10.4 code that our application uses. Exception in thread "Lucene Merge Thread #7" org.apache.lucene.index.MergePolicy$MergeException: java.lang.ArrayIndexOutOfBoundsException: 85 at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:549) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:522) Caused by: java.lang.ArrayIndexOutOfBoundsException: 85 at org.apache.lucene.codecs.lucene41.ForUtil.readBlock(ForUtil.java:206) at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.refillDocs(Lucene41PostingsReader.java:711) at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.nextDoc(Lucene41PostingsReader.java:780) at org.apache.lucene.codecs.MappingMultiDocsAndPositionsEnum.nextDoc(MappingMultiDocsAndPositionsEnum.java:104) at org.apache.lucene.codecs.PostingsConsumer.merge(PostingsConsumer.java:109) at org.apache.lucene.codecs.TermsConsumer.merge(TermsConsumer.java:164) at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:72) at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:399) at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:112) at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4223) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3811) at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:409) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:486) This is fully in the standard lucene code under heavy concurrency. The second piece of bad news is up to the point that this exception triggers Graal-0.11 is about 1/6th slower than hotspot (1.8.0_74). Graal 29 minutes 37 to HotSpot 25 minutes 14. If you are interested I can make both the code and data available for testing. The downside is the app is large and has a lot of dependencies and data going through (Needs 650gb of diskspace) and runs for about 30-40 hours on our hardware. Single thread limited in hotspot, in graal it seems to be slower in a fully threaded part. I can also give two different sampler profiles that might point to where the problem lies. If you have some kind of tutorial to retrieve the assembly from the above section I would be interested in helping out that way as well. I hope that this kind of feedback is useful and that I can make it actionable for you. The hardware is 24 cores of AMD Opteron 6348. With 256GB of ram, of which 16GB was set aside for this JVMs heap. If you are curious the app is www.uniprot.org. Regards, Jerven -- Jerven Tjalling Bolleman SIB | Swiss Institute of Bioinformatics CMU - 1, rue Michel Servet - 1211 Geneva 4 t: +41 22 379 58 85 - f: +41 22 379 58 58 Jerven.Bolleman at sib.swiss - http://www.sib.swiss From bahram.yarahmadi at gmail.com Mon Jun 6 09:51:07 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Mon, 6 Jun 2016 14:21:07 +0430 Subject: Graal JVMCI Problem In-Reply-To: References: Message-ID: Thanks Stefan I tried to test all arguments that you mentioned but none of them worked `mx -Mjit -v vm -version` output on my computer is : Setting environment variable JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 from /home/bahram/graal/graal-core/mx.graal-core/env Setting environment variable JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 from /home/bahram/graal/graal-core/mx.graal-core/env [project jdk.vm.ci.hotspot.jfr was removed as dependency JFR is missing] [jdk.vm.ci.hotspot.jfr was removed from distribution JVMCI_HOTSPOT] /home/bahram/graal/jvmci/jdk1.8.0_91/product/bin/java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -d64 -Djvmci.Compiler=graal -Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar -version openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) OpenJDK 64-Bit Server VM (build 25.66-b00-internal-jvmci-0.9-dev, mixed mode) Since I don't use truffle framework I changed it to graal-api.jar location but when I entered it as default vm argument in eclipse I get the same error ,finally I enterd jvmci-api.jar which is located in mx.build in jvmci directory but I get this error Exception in thread "main" java.lang.ExceptionInInitializerError Caused by: java.lang.UnsupportedOperationException: The VM does not support the Graal API. Currently used Java home directory is /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. Currently used VM configuration is: OpenJDK 64-Bit Server VM at com.oracle.graal.api.test.Graal.getRequiredCapability(Graal.java:78) at BahramMain.(BahramMain.java:26) I have cloned Graal repo from github yesterday I compiled it with mx --vm server build since 'mx build' does not ask me which graal configuration I want to use anymore and since I want to use graal just for some special methods which I specify I have to use graal in a hosted mode (server) What do you suggest me to do ? Thanks again Bahram On Sun, Jun 5, 2016 at 7:33 PM, Stefan Marr wrote: > Hi: > > Are you building Graal from the latest graal-core code? > > You?ll likely need extra arguments to the VM: -server > -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -d64 > -Djvmci.Compiler=graal > > And possibly: -XX:+UseJVMCICompiler depending on whether all Java code > should be compiled with it. > > To know what the correct way to invoke Java is, you can check mx. > > Something like `mx -Mjit -v vm -version` should print out the correct way > of invoking the JVM with Graal enabled. > > > Remi, the code at https://github.com/graalvm/graal-core build a Hotspot > for JDK 8 with JVMCI. > > Best regards > Stefan > > > On 05 Jun 2016, at 12:54, Bahram Yarahmadi > wrote: > > > > Hello guys, > > I made a very simple program ,which is : > > > > mport java.lang.reflect.Method; > > > > import com.oracle.graal.api.test.Graal; > > import com.oracle.graal.code.CompilationResult; > > import com.oracle.graal.compiler.GraalCompiler; > > import com.oracle.graal.compiler.target.Backend; > > import com.oracle.graal.lir.asm.CompilationResultBuilderFactory; > > import com.oracle.graal.lir.phases.LIRSuites; > > import com.oracle.graal.nodes.StructuredGraph; > > import com.oracle.graal.nodes.StructuredGraph.AllowAssumptions; > > import com.oracle.graal.phases.OptimisticOptimizations; > > import com.oracle.graal.phases.PhaseSuite; > > import com.oracle.graal.phases.tiers.HighTierContext; > > import com.oracle.graal.phases.tiers.Suites; > > import com.oracle.graal.phases.util.Providers; > > import com.oracle.graal.runtime.RuntimeProvider; > > > > import jdk.vm.ci.code.CodeCacheProvider; > > import jdk.vm.ci.code.CompiledCode; > > import jdk.vm.ci.code.InstalledCode; > > import jdk.vm.ci.meta.MetaAccessProvider; > > import jdk.vm.ci.meta.ProfilingInfo; > > import jdk.vm.ci.meta.ResolvedJavaMethod; > > > > public class BahramMain { > > public static RuntimeProvider > > runetimeProvider=Graal.getRequiredCapability(RuntimeProvider.class); > > public static Backend backend=runetimeProvider.getHostBackend(); > > public static MetaAccessProvider metaAccess=backend.getMetaAccess(); > > public static CodeCacheProvider codeCache=backend.getCodeCache(); > > public static Providers providers=backend.getProviders(); > > public static int addTwoIntegers(int x,int y){ > > if (x > y){ > > return x + y; > > } > > return x - y; > > } > > public static void main(String []args){ > > ResolvedJavaMethod method=findMethod(BahramMain.class, "addTwoIntegers"); > > StructuredGraph graph = new StructuredGraph(method, > AllowAssumptions.YES); > > > > /* > > * The phases used to build the graph. Usually this is just the > > GraphBuilderPhase. If > > * the graph already contains nodes, it is ignored. > > */ > > PhaseSuite graphBuilderSuite = > > backend.getSuites().getDefaultGraphBuilderSuite(); > > > > /* > > * The optimization phases that are applied to the graph. This is > > the main configuration > > * point for Graal. Add or remove phases to customize your > > compilation. > > */ > > Suites suites = backend.getSuites().getDefaultSuites(); > > > > /* > > * The low-level phases that are applied to the low-level > > representation. > > */ > > LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); > > > > /* > > * We want Graal to perform all speculative optimistic > > optimizations, using the > > * profiling information that comes with the method (collected by > > the interpreter) for > > * speculation. > > */ > > OptimisticOptimizations optimisticOpts = > > OptimisticOptimizations.ALL; > > ProfilingInfo profilingInfo = graph.getProfilingInfo(method); > > > > /* The default class and configuration for compilation results. */ > > CompilationResult compilationResult = new CompilationResult(); > > CompilationResultBuilderFactory factory = > > CompilationResultBuilderFactory.Default; > > > > /* Invoke the whole Graal compilation pipeline. */ > > GraalCompiler.compileGraph(graph, method, providers, backend, > > graphBuilderSuite, optimisticOpts, profilingInfo, suites, lirSuites, > > compilationResult, factory); > > > > /* > > * Install the compilation result into the VM, i.e., copy the > > byte[] array that contains > > * the machine code into an actual executable memory location. > > */ > > CompiledCode compiledCode = backend.createCompiledCode(method, > > compilationResult); > > InstalledCode installedCode = codeCache.addCode(method, > > compiledCode, null, null); > > System.out.println("The number Of methods in the graph is "+ > > graph.getNodeCount()); > > > > } > > public static ResolvedJavaMethod findMethod(Class declaringClass, > String > > name) { > > Method reflectionMethod = null; > > for (Method m : declaringClass.getDeclaredMethods()) { > > if (m.getName().equals(name)) { > > assert reflectionMethod == null : "More than one method with > > name " + name + " in class " + declaringClass.getName(); > > reflectionMethod = m; > > } > > } > > assert reflectionMethod != null : "No method with name " + name + " > > in class " + declaringClass.getName(); > > return metaAccess.lookupJavaMethod(reflectionMethod); > > } > > > > } > > but when I want to run it on eclipse with out unittest I get this error : > > Exception in thread "main" java.lang.ExceptionInInitializerError > > at BahramMain.(BahramMain.java:26) > > Caused by: java.lang.UnsupportedOperationException: The VM does not > support > > the JVMCI API. > > Currently used Java home directory is > > /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. > > Currently used VM configuration is: OpenJDK 64-Bit Server VM > > at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50) > > at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44) > > at com.oracle.graal.api.test.Graal.(Graal.java:40) > > ... 1 more > > -- > Stefan Marr > Johannes Kepler Universit?t Linz > http://stefan-marr.de/research/ > > > > From forax at univ-mlv.fr Mon Jun 6 10:26:48 2016 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 06 Jun 2016 10:26:48 +0000 Subject: Graal JVMCI Problem In-Reply-To: References: Message-ID: <340A64D1-8CE7-4639-B850-1B0B74EA374E@univ-mlv.fr> Ok, good to know. Regards, R?mi Le 5 juin 2016 17:03:03 CEST, Stefan Marr a ?crit : >Hi: > >Are you building Graal from the latest graal-core code? > >You?ll likely need extra arguments to the VM: -server >-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -d64 >-Djvmci.Compiler=graal > >And possibly: -XX:+UseJVMCICompiler depending on whether all Java code >should be compiled with it. > >To know what the correct way to invoke Java is, you can check mx. > >Something like `mx -Mjit -v vm -version` should print out the correct >way of invoking the JVM with Graal enabled. > > >Remi, the code at https://github.com/graalvm/graal-core build a Hotspot >for JDK 8 with JVMCI. > >Best regards >Stefan > >> On 05 Jun 2016, at 12:54, Bahram Yarahmadi > wrote: >> >> Hello guys, >> I made a very simple program ,which is : >> >> mport java.lang.reflect.Method; >> >> import com.oracle.graal.api.test.Graal; >> import com.oracle.graal.code.CompilationResult; >> import com.oracle.graal.compiler.GraalCompiler; >> import com.oracle.graal.compiler.target.Backend; >> import com.oracle.graal.lir.asm.CompilationResultBuilderFactory; >> import com.oracle.graal.lir.phases.LIRSuites; >> import com.oracle.graal.nodes.StructuredGraph; >> import com.oracle.graal.nodes.StructuredGraph.AllowAssumptions; >> import com.oracle.graal.phases.OptimisticOptimizations; >> import com.oracle.graal.phases.PhaseSuite; >> import com.oracle.graal.phases.tiers.HighTierContext; >> import com.oracle.graal.phases.tiers.Suites; >> import com.oracle.graal.phases.util.Providers; >> import com.oracle.graal.runtime.RuntimeProvider; >> >> import jdk.vm.ci.code.CodeCacheProvider; >> import jdk.vm.ci.code.CompiledCode; >> import jdk.vm.ci.code.InstalledCode; >> import jdk.vm.ci.meta.MetaAccessProvider; >> import jdk.vm.ci.meta.ProfilingInfo; >> import jdk.vm.ci.meta.ResolvedJavaMethod; >> >> public class BahramMain { >> public static RuntimeProvider >> runetimeProvider=Graal.getRequiredCapability(RuntimeProvider.class); >> public static Backend backend=runetimeProvider.getHostBackend(); >> public static MetaAccessProvider metaAccess=backend.getMetaAccess(); >> public static CodeCacheProvider codeCache=backend.getCodeCache(); >> public static Providers providers=backend.getProviders(); >> public static int addTwoIntegers(int x,int y){ >> if (x > y){ >> return x + y; >> } >> return x - y; >> } >> public static void main(String []args){ >> ResolvedJavaMethod method=findMethod(BahramMain.class, >"addTwoIntegers"); >> StructuredGraph graph = new StructuredGraph(method, >AllowAssumptions.YES); >> >> /* >> * The phases used to build the graph. Usually this is just the >> GraphBuilderPhase. If >> * the graph already contains nodes, it is ignored. >> */ >> PhaseSuite graphBuilderSuite = >> backend.getSuites().getDefaultGraphBuilderSuite(); >> >> /* >> * The optimization phases that are applied to the graph. This >is >> the main configuration >> * point for Graal. Add or remove phases to customize your >> compilation. >> */ >> Suites suites = backend.getSuites().getDefaultSuites(); >> >> /* >> * The low-level phases that are applied to the low-level >> representation. >> */ >> LIRSuites lirSuites = >backend.getSuites().getDefaultLIRSuites(); >> >> /* >> * We want Graal to perform all speculative optimistic >> optimizations, using the >> * profiling information that comes with the method (collected >by >> the interpreter) for >> * speculation. >> */ >> OptimisticOptimizations optimisticOpts = >> OptimisticOptimizations.ALL; >> ProfilingInfo profilingInfo = graph.getProfilingInfo(method); >> >> /* The default class and configuration for compilation results. >*/ >> CompilationResult compilationResult = new CompilationResult(); >> CompilationResultBuilderFactory factory = >> CompilationResultBuilderFactory.Default; >> >> /* Invoke the whole Graal compilation pipeline. */ >> GraalCompiler.compileGraph(graph, method, providers, backend, >> graphBuilderSuite, optimisticOpts, profilingInfo, suites, lirSuites, >> compilationResult, factory); >> >> /* >> * Install the compilation result into the VM, i.e., copy the >> byte[] array that contains >> * the machine code into an actual executable memory location. >> */ >> CompiledCode compiledCode = backend.createCompiledCode(method, >> compilationResult); >> InstalledCode installedCode = codeCache.addCode(method, >> compiledCode, null, null); >> System.out.println("The number Of methods in the graph is "+ >> graph.getNodeCount()); >> >> } >> public static ResolvedJavaMethod findMethod(Class declaringClass, >String >> name) { >> Method reflectionMethod = null; >> for (Method m : declaringClass.getDeclaredMethods()) { >> if (m.getName().equals(name)) { >> assert reflectionMethod == null : "More than one method >with >> name " + name + " in class " + declaringClass.getName(); >> reflectionMethod = m; >> } >> } >> assert reflectionMethod != null : "No method with name " + name >+ " >> in class " + declaringClass.getName(); >> return metaAccess.lookupJavaMethod(reflectionMethod); >> } >> >> } >> but when I want to run it on eclipse with out unittest I get this >error : >> Exception in thread "main" java.lang.ExceptionInInitializerError >> at BahramMain.(BahramMain.java:26) >> Caused by: java.lang.UnsupportedOperationException: The VM does not >support >> the JVMCI API. >> Currently used Java home directory is >> /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. >> Currently used VM configuration is: OpenJDK 64-Bit Server VM >> at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50) >> at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44) >> at com.oracle.graal.api.test.Graal.(Graal.java:40) >> ... 1 more From doug.simon at oracle.com Mon Jun 6 10:30:09 2016 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 6 Jun 2016 12:30:09 +0200 Subject: Problem with IGV In-Reply-To: References: <760508C2-8141-453C-B4C4-5C9286F646E7@oracle.com> <08AEE623-DC19-4652-BFBE-DB2F9891CE54@oracle.com> <0DA38775-0700-4BF0-B13E-E4667EB21B25@oracle.com> <21052C7B-3BCD-4C33-AED2-E10ECC1C26E4@oracle.com> Message-ID: I?ve never seen that. All I can suggest is deleting /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbplatform and running `mx itv` again to see if that fixes it. > On 05 Jun 2016, at 12:13, Bahram Yarahmadi wrote: > > Hello again guys, > I have another problem with IGV > When I want to run IGV for the first time ,I get this error > /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/build.xml:7: The following error occurred while executing this line: > /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/build-impl.xml:41: The following error occurred while executing this line: > /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/platform.xml:28: taskdef class org.netbeans.nbbuild.AutoUpdate cannot be found > using the classloader AntClassLoader[/tmp/tasks.jar] > > and task.jar is located in my tmp directory > > What should I do? > > Thanks > > Regards > > > On Tue, Mar 15, 2016 at 3:36 PM, Bahram Yarahmadi wrote: > Thanks ,You solved my problem > > Regards > > Bahram > > On Mon, Mar 14, 2016 at 7:37 PM, Doug Simon wrote: > Since IGV is launched with ant, you can specify ant proxies[1] via the ANT_OPTS environment variable. For example: > > $ export ANT_OPTS="-Dhttp.proxyHost=www-proxy.company.com -Dhttp.proxyPort=80? > $ mx igv > > -Doug > > [1] https://ant.apache.org/manual/proxy.html > > > On 14 Mar 2016, at 15:44, Bahram Yarahmadi wrote: > > > > Thanks Doug, > > You helped me a lot > > > > > > Regards , > > > > > > On Mon, Mar 14, 2016 at 6:00 PM, Bahram Yarahmadi wrote: > > I'm in iran and the url is not accesable for me ,But I can download the file with some proxy setting in my web brower !! > > > > > > On Mon, Mar 14, 2016 at 5:35 PM, Doug Simon wrote: > > Might be a network issue on your end as I can download http://updates.netbeans.org/netbeans/updates/7.4/uc/final/distribution/catalog.xml.gz fine. Can you download it in a browser? > > > > > > > On 14 Mar 2016, at 14:30, Bahram Yarahmadi wrote: > > > > > > Sorry Doug,Please accept my apology,The file was hidden and I didn't know > > > And the content of the file : > > > download: > > > [mkdir] Created dir: /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbplatform/harness > > > [echo] Downloading clusters ide|platform > > > [get] Getting: http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/netbeans/harness/tasks.jar > > > [get] To: /tmp/tasks.jar > > > [get] local file date : Mon Mar 14 09:12:41 IRST 2016 > > > [get] Not modified - so not downloaded > > > [autoupdate] Downloading http://updates.netbeans.org/netbeans/updates/7.4/uc/final/distribution/catalog.xml.gz > > > > > > BUILD FAILED > > > /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/build.xml:7: The following error occurred while executing this line: > > > /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/build-impl.xml:41: The following error occurred while executing this line: > > > /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/platform.xml:29: Server returned HTTP response code: 403 for URL: http://updates.netbeans.org/netbeans/updates/7.4/uc/final/distribution/catalog.xml.gz > > > > > > Total time: 11 seconds > > > > > > On Mon, Mar 14, 2016 at 4:46 PM, Doug Simon wrote: > > > > > > > On 14 Mar 2016, at 14:08, Bahram Yarahmadi wrote: > > > > > > > > There is no such file .ideal_graph_visualizer.log. > > > > > > This file is in the jvmci suite directory which I?m guessing is ../jvmci/.ideal_graph_visualizer.log or ../graal-jvmci-8/.ideal_graph_visualizer.log for you (assuming you are in the graal-core/ directory). > > > > > > -Doug > > > > > > > > > > > > From bahram.yarahmadi at gmail.com Mon Jun 6 11:28:22 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Mon, 6 Jun 2016 15:58:22 +0430 Subject: Problem with IGV In-Reply-To: References: <760508C2-8141-453C-B4C4-5C9286F646E7@oracle.com> <08AEE623-DC19-4652-BFBE-DB2F9891CE54@oracle.com> <0DA38775-0700-4BF0-B13E-E4667EB21B25@oracle.com> <21052C7B-3BCD-4C33-AED2-E10ECC1C26E4@oracle.com> Message-ID: Thanks my problem is solved On Mon, Jun 6, 2016 at 3:57 PM, Bahram Yarahmadi wrote: > Thanks Doug, > The problem is solved > > Thanks again > > On Mon, Jun 6, 2016 at 3:00 PM, Doug Simon wrote: > >> I?ve never seen that. All I can suggest is deleting >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbplatform >> and running `mx itv` again to see if that fixes it. >> >> > On 05 Jun 2016, at 12:13, Bahram Yarahmadi >> wrote: >> > >> > Hello again guys, >> > I have another problem with IGV >> > When I want to run IGV for the first time ,I get this error >> > >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/build.xml:7: >> The following error occurred while executing this line: >> > >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/build-impl.xml:41: >> The following error occurred while executing this line: >> > >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/platform.xml:28: >> taskdef class org.netbeans.nbbuild.AutoUpdate cannot be found >> > using the classloader AntClassLoader[/tmp/tasks.jar] >> > >> > and task.jar is located in my tmp directory >> > >> > What should I do? >> > >> > Thanks >> > >> > Regards >> > >> > >> > On Tue, Mar 15, 2016 at 3:36 PM, Bahram Yarahmadi < >> bahram.yarahmadi at gmail.com> wrote: >> > Thanks ,You solved my problem >> > >> > Regards >> > >> > Bahram >> > >> > On Mon, Mar 14, 2016 at 7:37 PM, Doug Simon >> wrote: >> > Since IGV is launched with ant, you can specify ant proxies[1] via the >> ANT_OPTS environment variable. For example: >> > >> > $ export ANT_OPTS="-Dhttp.proxyHost=www-proxy.company.com >> -Dhttp.proxyPort=80? >> > $ mx igv >> > >> > -Doug >> > >> > [1] https://ant.apache.org/manual/proxy.html >> > >> > > On 14 Mar 2016, at 15:44, Bahram Yarahmadi < >> bahram.yarahmadi at gmail.com> wrote: >> > > >> > > Thanks Doug, >> > > You helped me a lot >> > > >> > > >> > > Regards , >> > > >> > > >> > > On Mon, Mar 14, 2016 at 6:00 PM, Bahram Yarahmadi < >> bahram.yarahmadi at gmail.com> wrote: >> > > I'm in iran and the url is not accesable for me ,But I can download >> the file with some proxy setting in my web brower !! >> > > >> > > >> > > On Mon, Mar 14, 2016 at 5:35 PM, Doug Simon >> wrote: >> > > Might be a network issue on your end as I can download >> http://updates.netbeans.org/netbeans/updates/7.4/uc/final/distribution/catalog.xml.gz >> fine. Can you download it in a browser? >> > > >> > > >> > > > On 14 Mar 2016, at 14:30, Bahram Yarahmadi < >> bahram.yarahmadi at gmail.com> wrote: >> > > > >> > > > Sorry Doug,Please accept my apology,The file was hidden and I >> didn't know >> > > > And the content of the file : >> > > > download: >> > > > [mkdir] Created dir: >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbplatform/harness >> > > > [echo] Downloading clusters ide|platform >> > > > [get] Getting: >> http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/netbeans/harness/tasks.jar >> > > > [get] To: /tmp/tasks.jar >> > > > [get] local file date : Mon Mar 14 09:12:41 IRST 2016 >> > > > [get] Not modified - so not downloaded >> > > > [autoupdate] Downloading >> http://updates.netbeans.org/netbeans/updates/7.4/uc/final/distribution/catalog.xml.gz >> > > > >> > > > BUILD FAILED >> > > > >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/build.xml:7: >> The following error occurred while executing this line: >> > > > >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/build-impl.xml:41: >> The following error occurred while executing this line: >> > > > >> /home/bahram/graal/jvmci/src/share/tools/IdealGraphVisualizer/nbproject/platform.xml:29: >> Server returned HTTP response code: 403 for URL: >> http://updates.netbeans.org/netbeans/updates/7.4/uc/final/distribution/catalog.xml.gz >> > > > >> > > > Total time: 11 seconds >> > > > >> > > > On Mon, Mar 14, 2016 at 4:46 PM, Doug Simon >> wrote: >> > > > >> > > > > On 14 Mar 2016, at 14:08, Bahram Yarahmadi < >> bahram.yarahmadi at gmail.com> wrote: >> > > > > >> > > > > There is no such file .ideal_graph_visualizer.log. >> > > > >> > > > This file is in the jvmci suite directory which I?m guessing is >> ../jvmci/.ideal_graph_visualizer.log or >> ../graal-jvmci-8/.ideal_graph_visualizer.log for you (assuming you are in >> the graal-core/ directory). >> > > > >> > > > -Doug >> > > > >> > > >> > > >> > > >> > >> > >> > >> >> > From java at stefan-marr.de Mon Jun 6 11:45:52 2016 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 6 Jun 2016 13:45:52 +0200 Subject: Graal JVMCI Problem In-Reply-To: References: Message-ID: Hi Bahram: > On 06 Jun 2016, at 11:51, Bahram Yarahmadi wrote: > > I tried to test all arguments that you mentioned but none of them worked > `mx -Mjit -v vm -version` output on my computer is : > /home/bahram/graal/jvmci/jdk1.8.0_91/product/bin/java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -d64 -Djvmci.Compiler=graal -Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar -version > openjdk version "1.8.0_91" > OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) > OpenJDK 64-Bit Server VM (build 25.66-b00-internal-jvmci-0.9-dev, mixed mode) Ok, so, that seems to be working correctly. > Since I don?t use truffle framework I changed it to graal-api.jar location Ehm, I don?t think this is necessary. Just remove the `-Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar` if you don?t want to use truffle. I?d assume that the rest works automatically, without having to add any graal-specific jars. > I compiled it with mx --vm server build since 'mx build' does not ask me which graal configuration I want to use anymore > and since I want to use graal just for some special methods which I specify I have to use graal in a hosted mode (server) With the latest changes, everything is built into the same binary. The flags as above but excluding -XX:+UseJVMCICompiler correspond to the hosted mode. Best regards Stefan -- Stefan Marr Johannes Kepler Universit?t Linz http://stefan-marr.de/research/ From bahram.yarahmadi at gmail.com Mon Jun 6 12:07:18 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Mon, 6 Jun 2016 16:37:18 +0430 Subject: Graal JVMCI Problem In-Reply-To: References: Message-ID: I entered -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -d64 -Djvmci.Compiler=graal as my vm default arg in eclipse but it didn't work then I tried this -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -d64 -Djvmci.Compiler=graal and it didn't work too I always get the same error which is : Exception in thread "main" java.lang.ExceptionInInitializerError at BahramMain.(BahramMain.java:26) Caused by: java.lang.UnsupportedOperationException: The VM does not support the JVMCI API. Currently used Java home directory is /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. Currently used VM configuration is: OpenJDK 64-Bit Server VM at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50) at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44) at com.oracle.graal.api.test.Graal.(Graal.java:40) ... 1 more Thanks again Regards On Mon, Jun 6, 2016 at 4:15 PM, Stefan Marr wrote: > Hi Bahram: > > > > On 06 Jun 2016, at 11:51, Bahram Yarahmadi > wrote: > > > > I tried to test all arguments that you mentioned but none of them worked > > `mx -Mjit -v vm -version` output on my computer is : > > /home/bahram/graal/jvmci/jdk1.8.0_91/product/bin/java -server > -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler > -d64 -Djvmci.Compiler=graal > -Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar > -version > > openjdk version "1.8.0_91" > > OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) > > OpenJDK 64-Bit Server VM (build 25.66-b00-internal-jvmci-0.9-dev, mixed > mode) > > Ok, so, that seems to be working correctly. > > > Since I don?t use truffle framework I changed it to graal-api.jar > location > > Ehm, I don?t think this is necessary. Just remove the > `-Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar` > if you don?t want to use truffle. I?d assume that the rest works > automatically, without having to add any graal-specific jars. > > > I compiled it with mx --vm server build since 'mx build' does not ask me > which graal configuration I want to use anymore > > and since I want to use graal just for some special methods which I > specify I have to use graal in a hosted mode (server) > > With the latest changes, everything is built into the same binary. The > flags as above but excluding -XX:+UseJVMCICompiler correspond to the hosted > mode. > > Best regards > Stefan > > > > > -- > Stefan Marr > Johannes Kepler Universit?t Linz > http://stefan-marr.de/research/ > > > > From roland.schatz at oracle.com Mon Jun 6 12:27:38 2016 From: roland.schatz at oracle.com (Roland Schatz) Date: Mon, 6 Jun 2016 14:27:38 +0200 Subject: Graal JVMCI Problem In-Reply-To: References: Message-ID: <833d284a-727f-a533-1470-7b7177d5f28a@oracle.com> On 06/06/2016 02:07 PM, Bahram Yarahmadi wrote: > I entered -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI > -XX:+UseJVMCICompiler -d64 -Djvmci.Compiler=graal as my vm default arg in > eclipse but it didn't work > then I tried this -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI > -d64 -Djvmci.Compiler=graal and it didn't work too > I always get the same error which is : > Exception in thread "main" java.lang.ExceptionInInitializerError > at BahramMain.(BahramMain.java:26) > Caused by: java.lang.UnsupportedOperationException: The VM does not support > the JVMCI API. > Currently used Java home directory is > /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. > Currently used VM configuration is: OpenJDK 64-Bit Server VM > at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50) > at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44) > at com.oracle.graal.api.test.Graal.(Graal.java:40) > ... 1 more This looks like a classloader problem. Can you try running with the `-XX:-UseJVMCIClassLoader` option? Since JVMCI is a security critical interface (you can basically do everything with it via installing bad code), normal application code can not access it. This is enforced with a special classloader. As a workaround you can disable this security mechanism with `-XX:-UseJVMCIClassLoader`. With this option, the JVMCI API is in the boot classpath and everyone is allowed to use it. Note that this will change with JDK-9, where more fine-grained access control is available with the new module system. - Roland > > > Thanks again > > Regards > > > On Mon, Jun 6, 2016 at 4:15 PM, Stefan Marr wrote: > >> Hi Bahram: >> >> >>> On 06 Jun 2016, at 11:51, Bahram Yarahmadi >> wrote: >>> I tried to test all arguments that you mentioned but none of them worked >>> `mx -Mjit -v vm -version` output on my computer is : >>> /home/bahram/graal/jvmci/jdk1.8.0_91/product/bin/java -server >> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler >> -d64 -Djvmci.Compiler=graal >> -Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar >> -version >>> openjdk version "1.8.0_91" >>> OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) >>> OpenJDK 64-Bit Server VM (build 25.66-b00-internal-jvmci-0.9-dev, mixed >> mode) >> >> Ok, so, that seems to be working correctly. >> >>> Since I don?t use truffle framework I changed it to graal-api.jar >> location >> >> Ehm, I don?t think this is necessary. Just remove the >> `-Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar` >> if you don?t want to use truffle. I?d assume that the rest works >> automatically, without having to add any graal-specific jars. >> >>> I compiled it with mx --vm server build since 'mx build' does not ask me >> which graal configuration I want to use anymore >>> and since I want to use graal just for some special methods which I >> specify I have to use graal in a hosted mode (server) >> >> With the latest changes, everything is built into the same binary. The >> flags as above but excluding -XX:+UseJVMCICompiler correspond to the hosted >> mode. >> >> Best regards >> Stefan >> >> >> >> >> -- >> Stefan Marr >> Johannes Kepler Universit?t Linz >> http://stefan-marr.de/research/ >> >> >> >> From bahram.yarahmadi at gmail.com Mon Jun 6 13:09:54 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Mon, 6 Jun 2016 17:39:54 +0430 Subject: Graal JVMCI Problem In-Reply-To: <833d284a-727f-a533-1470-7b7177d5f28a@oracle.com> References: <833d284a-727f-a533-1470-7b7177d5f28a@oracle.com> Message-ID: You are right ,It worked Ronald I owe you too much and I can't thank you enough Thank you all specially Stefan and Ronald Regrads On Mon, Jun 6, 2016 at 4:57 PM, Roland Schatz wrote: > On 06/06/2016 02:07 PM, Bahram Yarahmadi wrote: > >> I entered -server -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI >> -XX:+UseJVMCICompiler -d64 -Djvmci.Compiler=graal as my vm default arg in >> eclipse but it didn't work >> then I tried this -server -XX:+UnlockExperimentalVMOptions >> -XX:+EnableJVMCI >> -d64 -Djvmci.Compiler=graal and it didn't work too >> I always get the same error which is : >> Exception in thread "main" java.lang.ExceptionInInitializerError >> at BahramMain.(BahramMain.java:26) >> Caused by: java.lang.UnsupportedOperationException: The VM does not >> support >> the JVMCI API. >> Currently used Java home directory is >> /home/bahram/graal/jvmci/jdk1.8.0_91/product/jre. >> Currently used VM configuration is: OpenJDK 64-Bit Server VM >> at jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:50) >> at com.oracle.graal.api.test.Graal.initializeRuntime(Graal.java:44) >> at com.oracle.graal.api.test.Graal.(Graal.java:40) >> ... 1 more >> > > This looks like a classloader problem. Can you try running with the > `-XX:-UseJVMCIClassLoader` option? > > Since JVMCI is a security critical interface (you can basically do > everything with it via installing bad code), normal application code can > not access it. This is enforced with a special classloader. As a workaround > you can disable this security mechanism with `-XX:-UseJVMCIClassLoader`. > With this option, the JVMCI API is in the boot classpath and everyone is > allowed to use it. > > Note that this will change with JDK-9, where more fine-grained access > control is available with the new module system. > > > - Roland > > > >> >> Thanks again >> >> Regards >> >> >> On Mon, Jun 6, 2016 at 4:15 PM, Stefan Marr wrote: >> >> Hi Bahram: >>> >>> >>> On 06 Jun 2016, at 11:51, Bahram Yarahmadi >>>> >>> wrote: >>> >>>> I tried to test all arguments that you mentioned but none of them worked >>>> `mx -Mjit -v vm -version` output on my computer is : >>>> /home/bahram/graal/jvmci/jdk1.8.0_91/product/bin/java -server >>>> >>> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler >>> -d64 -Djvmci.Compiler=graal >>> >>> -Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar >>> -version >>> >>>> openjdk version "1.8.0_91" >>>> OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) >>>> OpenJDK 64-Bit Server VM (build 25.66-b00-internal-jvmci-0.9-dev, mixed >>>> >>> mode) >>> >>> Ok, so, that seems to be working correctly. >>> >>> Since I don?t use truffle framework I changed it to graal-api.jar >>>> >>> location >>> >>> Ehm, I don?t think this is necessary. Just remove the >>> >>> `-Xbootclasspath/p:/home/bahram/graal/truffle/mxbuild/dists/truffle-api.jar` >>> if you don?t want to use truffle. I?d assume that the rest works >>> automatically, without having to add any graal-specific jars. >>> >>> I compiled it with mx --vm server build since 'mx build' does not ask me >>>> >>> which graal configuration I want to use anymore >>> >>>> and since I want to use graal just for some special methods which I >>>> >>> specify I have to use graal in a hosted mode (server) >>> >>> With the latest changes, everything is built into the same binary. The >>> flags as above but excluding -XX:+UseJVMCICompiler correspond to the >>> hosted >>> mode. >>> >>> Best regards >>> Stefan >>> >>> >>> >>> >>> -- >>> Stefan Marr >>> Johannes Kepler Universit?t Linz >>> http://stefan-marr.de/research/ >>> >>> >>> >>> >>> > From doug.simon at oracle.com Mon Jun 6 13:58:56 2016 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 6 Jun 2016 15:58:56 +0200 Subject: Transition to JVMCI JDK8 (removing jvmci suite dependency) Message-ID: We will soon be removing the jvmci suite dependency from graal-core. Instead, you will use a JVMCI enabled JDK to develop/run Graal. I will send a more detailed message about the transition once we?ve made it, including where you can download JVMCI enabled JDKs. Unfortunately, I updated the jvmci import dependency in graal-core to fix a build issue[1] without realizing it also included another change to the way VMs are built and run[2] that was in preparation for the aforementioned transition. As such, I?m documenting the command line changes here. The usage changes reflect that fact that a single VM binary can be used for both hosted and non-hosted execution. New usage without mx: "-XX:-UseJVMCICompiler" selects hosted mode (the default) "-XX:+UseJVMCICompiler" selects jvmci as system compiler "-XX:+/-EnableJVMCI" does nothing, it exists just for jdk9 compatibility (+ is the default, - prints a warning that it doesn't actually do anything) New usage with mx: "--vm server" or "DEFAULT_VM=server" is now the default (no need to specify DEFAULT_VM anymore) "-Mhosted" selects hosted mode (the default) "-Mjit" selects jvmci as system compiler "--vm jvmci" still exists for backwards compatibility, it's rewritten by mx to "--vm server -Mjit" (and will print a deprecation warning) Note that the mx usage above will change once the jvmci suite dependency is removed. The details will be in the message announcing the transition. -Doug [1] https://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-8/rev/b2ca0db14546 [2] https://lafo.ssw.uni-linz.ac.at/hg/graal-jvmci-8/rev/3ef45d0a6d77 From tom.rodriguez at oracle.com Mon Jun 6 20:41:19 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 6 Jun 2016 13:41:19 -0700 Subject: IGV Message-ID: <75C71DE6-120D-46D0-BB53-2398778E4F42@oracle.com> In preparation for the removal of JVMCI as a suite dependency, IGV has been converted into a standalone download like the C1Visualizer. The latest graal-core will now download and launch it for you instead of building it. I also moved the hcfdis, hsdis and jol commands into graal-core, so let me know if you have any issues launching these tools after updating. tom From java at stefan-marr.de Tue Jun 7 09:30:34 2016 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 7 Jun 2016 11:30:34 +0200 Subject: Call for Participation: 3rd Virtual Machine Meetup, September 1-2, Lugano, Switzerland Message-ID: <11AD46E1-49D7-480F-8FB4-36E5B458BA7F@stefan-marr.de> # Virtual Machine Meetup ## Call for Participation at the VMM2016 The 3rd Virtual Machine Meetup (VMM'16) is a venue for discussing the latest research and developments in the area of managed language execution. It will be held on 1st and 2nd of September at the Universit? della Svizzera italiana (USI), Lugano, Switzerland and is part of the Managed Languages & Runtimes Week 2016 (http://manlang16.inf.usi.ch/, other colocated events are PPPJ'16 and JTRES'16, room Auditorium from 9am - 5pm). We welcome presentations of new research results, experience reports, as well as position statements that can lead to interesting discussions. Topics include, but are not limited to: - Programming language design - Dynamic and static program analysis - Compiler construction - Managed runtime architectures - Data processing engines - Distributed execution environments To participate, please email thomas.wuerthinger at oracle.com stating your wish to attend, and your name and affiliation as you wish to have them on your name badge. There are limited participant slots due to the constraints of the room, so please register early, and by July 20th the latest. If you would like to give a presentation, please email Thomas with a title (max. 100 characters) and abstract (max. 400 characters). We may ask for additional information from you before making the program decision. Presentation slots are either 30 minutes (long) or 15 minutes (short) including Q/A. Important dates: - Submissions: July 10, 2016 - Author notification: July 17, 2016 - Registration for participation: July 20, 2016 - Virtual machine Meetup: Sep 1st + 2nd 2016 at USI Lugano - Social Event: Sep 3rd 2016, optional Program committee: - Stefan Marr, JKU Linz, Austria - Matthias Grimmer, JKU Linz, Austria - Laurence Tratt, King's College London - Thomas Wuerthinger, Oracle Labs Switzerland As an optional social event, we will plan this year for Saturday the 3rd of September a trip to the Lake Como - a gorgeous lake in Italy close to Lugano. Please let us know whether you intend to participate for planning purposes. From gilles.m.duboscq at oracle.com Tue Jun 7 09:50:08 2016 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Tue, 7 Jun 2016 11:50:08 +0200 Subject: Experimenting with running a java process on graalvm-0.11-dev-dk In-Reply-To: References: Message-ID: Hi Jarven, Thank you for the report! Can you give 0.12 [1] a try? Is there no smaller dataset we could test this on? Gilles [1] http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html On 06/06/16 09:18, Jerven Tjalling Bolleman wrote: > Dear Graal developers, > > Last week I started experimenting with running a largish Java application on graal to see the difference with standard hotspot. > > There are two pieces of sad news I have to report. The first is there are exceptions occurring in the code that are only triggered when running graal. Specifically, in the Lucene 4.10.4 code that our application uses. > > Exception in thread "Lucene Merge Thread #7" org.apache.lucene.index.MergePolicy$MergeException: java.lang.ArrayIndexOutOfBoundsException: 85 > at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:549) > at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:522) > Caused by: java.lang.ArrayIndexOutOfBoundsException: 85 > at org.apache.lucene.codecs.lucene41.ForUtil.readBlock(ForUtil.java:206) > at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.refillDocs(Lucene41PostingsReader.java:711) > at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.nextDoc(Lucene41PostingsReader.java:780) > at org.apache.lucene.codecs.MappingMultiDocsAndPositionsEnum.nextDoc(MappingMultiDocsAndPositionsEnum.java:104) > at org.apache.lucene.codecs.PostingsConsumer.merge(PostingsConsumer.java:109) > at org.apache.lucene.codecs.TermsConsumer.merge(TermsConsumer.java:164) > at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:72) > at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:399) > at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:112) > at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4223) > at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3811) > at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:409) > at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:486) > > This is fully in the standard lucene code under heavy concurrency. > > The second piece of bad news is up to the point that this exception triggers Graal-0.11 is about 1/6th slower than hotspot (1.8.0_74). > > Graal 29 minutes 37 to HotSpot 25 minutes 14. > > If you are interested I can make both the code and data available for testing. > The downside is the app is large and has a lot of dependencies and data going through (Needs 650gb of diskspace) and runs for about 30-40 hours on our hardware. > Single thread limited in hotspot, in graal it seems to be slower in a fully threaded part. > > I can also give two different sampler profiles that might point to where the problem lies. > > If you have some kind of tutorial to retrieve the assembly from the above section I would be interested in helping out that way as well. > > I hope that this kind of feedback is useful and that I can make it actionable for you. > > The hardware is 24 cores of AMD Opteron 6348. With 256GB of ram, of which 16GB was set aside for this JVMs heap. If you are curious the app is www.uniprot.org. > > Regards, > Jerven From jerven.bolleman at sib.swiss Tue Jun 7 10:16:19 2016 From: jerven.bolleman at sib.swiss (Jerven Bolleman) Date: Tue, 7 Jun 2016 12:16:19 +0200 Subject: Experimenting with running a java process on graalvm-0.11-dev-dk In-Reply-To: References: Message-ID: Hi Giles, > On 07 Jun 2016, at 11:50, Gilles Duboscq wrote: > > Hi Jerven, > > Thank you for the report! > > Can you give 0.12 [1] a try? Will do, off site and VPN to my office is blocked right now. Hope to be able to give you the answer by next week Monday. > Is there no smaller dataset we could test this on? Speed wise yes definitely 10GB should be ok for a significant result. For the Lucene error, as well but that would be a bit more work to make sure it replicates on smaller systems. If you are interested in that I can make a pure java build (currently we use out of process XZ decompression) Regards, Jerven > > Gilles > > [1] http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html > > On 06/06/16 09:18, Jerven Tjalling Bolleman wrote: >> Dear Graal developers, >> >> Last week I started experimenting with running a largish Java application on graal to see the difference with standard hotspot. >> >> There are two pieces of sad news I have to report. The first is there are exceptions occurring in the code that are only triggered when running graal. Specifically, in the Lucene 4.10.4 code that our application uses. >> >> Exception in thread "Lucene Merge Thread #7" org.apache.lucene.index.MergePolicy$MergeException: java.lang.ArrayIndexOutOfBoundsException: 85 >> at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:549) >> at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:522) >> Caused by: java.lang.ArrayIndexOutOfBoundsException: 85 >> at org.apache.lucene.codecs.lucene41.ForUtil.readBlock(ForUtil.java:206) >> at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.refillDocs(Lucene41PostingsReader.java:711) >> at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.nextDoc(Lucene41PostingsReader.java:780) >> at org.apache.lucene.codecs.MappingMultiDocsAndPositionsEnum.nextDoc(MappingMultiDocsAndPositionsEnum.java:104) >> at org.apache.lucene.codecs.PostingsConsumer.merge(PostingsConsumer.java:109) >> at org.apache.lucene.codecs.TermsConsumer.merge(TermsConsumer.java:164) >> at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:72) >> at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:399) >> at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:112) >> at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4223) >> at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3811) >> at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:409) >> at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:486) >> >> This is fully in the standard lucene code under heavy concurrency. >> >> The second piece of bad news is up to the point that this exception triggers Graal-0.11 is about 1/6th slower than hotspot (1.8.0_74). >> >> Graal 29 minutes 37 to HotSpot 25 minutes 14. >> >> If you are interested I can make both the code and data available for testing. >> The downside is the app is large and has a lot of dependencies and data going through (Needs 650gb of diskspace) and runs for about 30-40 hours on our hardware. >> Single thread limited in hotspot, in graal it seems to be slower in a fully threaded part. >> >> I can also give two different sampler profiles that might point to where the problem lies. >> >> If you have some kind of tutorial to retrieve the assembly from the above section I would be interested in helping out that way as well. >> >> I hope that this kind of feedback is useful and that I can make it actionable for you. >> >> The hardware is 24 cores of AMD Opteron 6348. With 256GB of ram, of which 16GB was set aside for this JVMs heap. If you are curious the app is www.uniprot.org. >> >> Regards, >> Jerven From gilles.m.duboscq at oracle.com Tue Jun 7 12:41:02 2016 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Tue, 7 Jun 2016 14:41:02 +0200 Subject: Experimenting with running a java process on graalvm-0.11-dev-dk In-Reply-To: References: Message-ID: On 07/06/16 12:16, Jerven Bolleman wrote: > Hi Giles, > >> On 07 Jun 2016, at 11:50, Gilles Duboscq wrote: >> >> Hi Jerven, >> >> Thank you for the report! >> >> Can you give 0.12 [1] a try? > Will do, off site and VPN to my office is blocked right now. > Hope to be able to give you the answer by next week Monday. >> Is there no smaller dataset we could test this on? > Speed wise yes definitely 10GB should be ok for a significant result. > For the Lucene error, as well but that would be a bit more > work to make sure it replicates on smaller systems. > > If you are interested in that I can make a pure java build > (currently we use out of process XZ decompression) If the 0.12 results are still bad, yes, that would be interesting. Gilles > > Regards, > Jerven >> >> Gilles >> >> [1] http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html >> >> On 06/06/16 09:18, Jerven Tjalling Bolleman wrote: >>> Dear Graal developers, >>> >>> Last week I started experimenting with running a largish Java application on graal to see the difference with standard hotspot. >>> >>> There are two pieces of sad news I have to report. The first is there are exceptions occurring in the code that are only triggered when running graal. Specifically, in the Lucene 4.10.4 code that our application uses. >>> >>> Exception in thread "Lucene Merge Thread #7" org.apache.lucene.index.MergePolicy$MergeException: java.lang.ArrayIndexOutOfBoundsException: 85 >>> at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:549) >>> at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:522) >>> Caused by: java.lang.ArrayIndexOutOfBoundsException: 85 >>> at org.apache.lucene.codecs.lucene41.ForUtil.readBlock(ForUtil.java:206) >>> at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.refillDocs(Lucene41PostingsReader.java:711) >>> at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.nextDoc(Lucene41PostingsReader.java:780) >>> at org.apache.lucene.codecs.MappingMultiDocsAndPositionsEnum.nextDoc(MappingMultiDocsAndPositionsEnum.java:104) >>> at org.apache.lucene.codecs.PostingsConsumer.merge(PostingsConsumer.java:109) >>> at org.apache.lucene.codecs.TermsConsumer.merge(TermsConsumer.java:164) >>> at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:72) >>> at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:399) >>> at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:112) >>> at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4223) >>> at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3811) >>> at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:409) >>> at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:486) >>> >>> This is fully in the standard lucene code under heavy concurrency. >>> >>> The second piece of bad news is up to the point that this exception triggers Graal-0.11 is about 1/6th slower than hotspot (1.8.0_74). >>> >>> Graal 29 minutes 37 to HotSpot 25 minutes 14. >>> >>> If you are interested I can make both the code and data available for testing. >>> The downside is the app is large and has a lot of dependencies and data going through (Needs 650gb of diskspace) and runs for about 30-40 hours on our hardware. >>> Single thread limited in hotspot, in graal it seems to be slower in a fully threaded part. >>> >>> I can also give two different sampler profiles that might point to where the problem lies. >>> >>> If you have some kind of tutorial to retrieve the assembly from the above section I would be interested in helping out that way as well. >>> >>> I hope that this kind of feedback is useful and that I can make it actionable for you. >>> >>> The hardware is 24 cores of AMD Opteron 6348. With 256GB of ram, of which 16GB was set aside for this JVMs heap. If you are curious the app is www.uniprot.org. >>> >>> Regards, >>> Jerven > From michael.c.berg at intel.com Wed Jun 8 21:35:18 2016 From: michael.c.berg at intel.com (Berg, Michael C) Date: Wed, 8 Jun 2016 21:35:18 +0000 Subject: code review request Message-ID: Folks, the code is available as: https://github.com/graalvm/graal-core/pull/187 For review. This change stages the first installment of intel libm intrinsics (log and log10). Both offer performance uplift of about 1.68x and 1.75x respectively and are fully tested. Regards, Michael From jerven.bolleman at sib.swiss Thu Jun 9 15:26:27 2016 From: jerven.bolleman at sib.swiss (Jerven Bolleman) Date: Thu, 9 Jun 2016 17:26:27 +0200 Subject: Good on 0.12 [Was: Re: Experimenting with running a java process on graalvm-0.11-dev-dk] In-Reply-To: References: Message-ID: <8B03D8CF-5066-4EB4-8A0C-9AEB218BBC10@sib.swiss> Dear Gilles, Graal-0.12 continues past the break point and seems to be faster than current hotspot. 30 minutes on 15 hours is a nice boost. store_graal12.log:[transaction:uniprot.transaction] DEBUG: Processed uniprot.rdf.xz: 128674895 entries (0 bytes) in 14:24:23.139) store_norm.log:[transaction:uniprot.transaction] DEBUG: Processed uniprot.rdf.xz: 128674895 entries (0 bytes) in 14:53:04.781) Will run it a small number of times to make sure this is significant. Key take away is that Graal does work for real applications with complicated runtimes. Congratulations! Regards, Jerven > On 07 Jun 2016, at 14:41, Gilles Duboscq wrote: > > > > On 07/06/16 12:16, Jerven Bolleman wrote: >> Hi Giles, >> >>> On 07 Jun 2016, at 11:50, Gilles Duboscq wrote: >>> >>> Hi Jerven, >>> >>> Thank you for the report! >>> >>> Can you give 0.12 [1] a try? >> Will do, off site and VPN to my office is blocked right now. >> Hope to be able to give you the answer by next week Monday. >>> Is there no smaller dataset we could test this on? >> Speed wise yes definitely 10GB should be ok for a significant result. >> For the Lucene error, as well but that would be a bit more >> work to make sure it replicates on smaller systems. >> >> If you are interested in that I can make a pure java build >> (currently we use out of process XZ decompression) > > If the 0.12 results are still bad, yes, that would be interesting. > > Gilles > >> >> Regards, >> Jerven >>> >>> Gilles >>> >>> [1] http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html >>> >>> On 06/06/16 09:18, Jerven Tjalling Bolleman wrote: >>>> Dear Graal developers, >>>> >>>> Last week I started experimenting with running a largish Java application on graal to see the difference with standard hotspot. >>>> >>>> There are two pieces of sad news I have to report. The first is there are exceptions occurring in the code that are only triggered when running graal. Specifically, in the Lucene 4.10.4 code that our application uses. >>>> >>>> Exception in thread "Lucene Merge Thread #7" org.apache.lucene.index.MergePolicy$MergeException: java.lang.ArrayIndexOutOfBoundsException: 85 >>>> at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:549) >>>> at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:522) >>>> Caused by: java.lang.ArrayIndexOutOfBoundsException: 85 >>>> at org.apache.lucene.codecs.lucene41.ForUtil.readBlock(ForUtil.java:206) >>>> at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.refillDocs(Lucene41PostingsReader.java:711) >>>> at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.nextDoc(Lucene41PostingsReader.java:780) >>>> at org.apache.lucene.codecs.MappingMultiDocsAndPositionsEnum.nextDoc(MappingMultiDocsAndPositionsEnum.java:104) >>>> at org.apache.lucene.codecs.PostingsConsumer.merge(PostingsConsumer.java:109) >>>> at org.apache.lucene.codecs.TermsConsumer.merge(TermsConsumer.java:164) >>>> at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:72) >>>> at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:399) >>>> at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:112) >>>> at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4223) >>>> at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3811) >>>> at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:409) >>>> at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:486) >>>> >>>> This is fully in the standard lucene code under heavy concurrency. >>>> >>>> The second piece of bad news is up to the point that this exception triggers Graal-0.11 is about 1/6th slower than hotspot (1.8.0_74). >>>> >>>> Graal 29 minutes 37 to HotSpot 25 minutes 14. >>>> >>>> If you are interested I can make both the code and data available for testing. >>>> The downside is the app is large and has a lot of dependencies and data going through (Needs 650gb of diskspace) and runs for about 30-40 hours on our hardware. >>>> Single thread limited in hotspot, in graal it seems to be slower in a fully threaded part. >>>> >>>> I can also give two different sampler profiles that might point to where the problem lies. >>>> >>>> If you have some kind of tutorial to retrieve the assembly from the above section I would be interested in helping out that way as well. >>>> >>>> I hope that this kind of feedback is useful and that I can make it actionable for you. >>>> >>>> The hardware is 24 cores of AMD Opteron 6348. With 256GB of ram, of which 16GB was set aside for this JVMs heap. If you are curious the app is www.uniprot.org. >>>> >>>> Regards, >>>> Jerven From gilles.m.duboscq at oracle.com Thu Jun 9 15:40:13 2016 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Thu, 9 Jun 2016 17:40:13 +0200 Subject: Good on 0.12 [Was: Re: Experimenting with running a java process on graalvm-0.11-dev-dk] In-Reply-To: <8B03D8CF-5066-4EB4-8A0C-9AEB218BBC10@sib.swiss> References: <8B03D8CF-5066-4EB4-8A0C-9AEB218BBC10@sib.swiss> Message-ID: <897c6a61-9bb3-7d20-eec9-32215bba9108@oracle.com> Hi Jerven Thank you for the update. I'm glad to hear 0.12 works better. Tell us if you notice any other problem. Gilles On 09/06/16 17:26, Jerven Bolleman wrote: > Dear Gilles, > > Graal-0.12 continues past the break point and seems to be faster than current hotspot. > 30 minutes on 15 hours is a nice boost. > > store_graal12.log:[transaction:uniprot.transaction] DEBUG: Processed uniprot.rdf.xz: 128674895 entries (0 bytes) in 14:24:23.139) > store_norm.log:[transaction:uniprot.transaction] DEBUG: Processed uniprot.rdf.xz: 128674895 entries (0 bytes) in 14:53:04.781) > > Will run it a small number of times to make sure this is significant. Key take away is that Graal does work for real > applications with complicated runtimes. Congratulations! > > Regards, > Jerven > >> On 07 Jun 2016, at 14:41, Gilles Duboscq wrote: >> >> >> >> On 07/06/16 12:16, Jerven Bolleman wrote: >>> Hi Giles, >>> >>>> On 07 Jun 2016, at 11:50, Gilles Duboscq wrote: >>>> >>>> Hi Jerven, >>>> >>>> Thank you for the report! >>>> >>>> Can you give 0.12 [1] a try? >>> Will do, off site and VPN to my office is blocked right now. >>> Hope to be able to give you the answer by next week Monday. >>>> Is there no smaller dataset we could test this on? >>> Speed wise yes definitely 10GB should be ok for a significant result. >>> For the Lucene error, as well but that would be a bit more >>> work to make sure it replicates on smaller systems. >>> >>> If you are interested in that I can make a pure java build >>> (currently we use out of process XZ decompression) >> >> If the 0.12 results are still bad, yes, that would be interesting. >> >> Gilles >> >>> >>> Regards, >>> Jerven >>>> >>>> Gilles >>>> >>>> [1] http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html >>>> >>>> On 06/06/16 09:18, Jerven Tjalling Bolleman wrote: >>>>> Dear Graal developers, >>>>> >>>>> Last week I started experimenting with running a largish Java application on graal to see the difference with standard hotspot. >>>>> >>>>> There are two pieces of sad news I have to report. The first is there are exceptions occurring in the code that are only triggered when running graal. Specifically, in the Lucene 4.10.4 code that our application uses. >>>>> >>>>> Exception in thread "Lucene Merge Thread #7" org.apache.lucene.index.MergePolicy$MergeException: java.lang.ArrayIndexOutOfBoundsException: 85 >>>>> at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:549) >>>>> at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:522) >>>>> Caused by: java.lang.ArrayIndexOutOfBoundsException: 85 >>>>> at org.apache.lucene.codecs.lucene41.ForUtil.readBlock(ForUtil.java:206) >>>>> at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.refillDocs(Lucene41PostingsReader.java:711) >>>>> at org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.nextDoc(Lucene41PostingsReader.java:780) >>>>> at org.apache.lucene.codecs.MappingMultiDocsAndPositionsEnum.nextDoc(MappingMultiDocsAndPositionsEnum.java:104) >>>>> at org.apache.lucene.codecs.PostingsConsumer.merge(PostingsConsumer.java:109) >>>>> at org.apache.lucene.codecs.TermsConsumer.merge(TermsConsumer.java:164) >>>>> at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:72) >>>>> at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:399) >>>>> at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:112) >>>>> at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4223) >>>>> at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3811) >>>>> at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:409) >>>>> at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:486) >>>>> >>>>> This is fully in the standard lucene code under heavy concurrency. >>>>> >>>>> The second piece of bad news is up to the point that this exception triggers Graal-0.11 is about 1/6th slower than hotspot (1.8.0_74). >>>>> >>>>> Graal 29 minutes 37 to HotSpot 25 minutes 14. >>>>> >>>>> If you are interested I can make both the code and data available for testing. >>>>> The downside is the app is large and has a lot of dependencies and data going through (Needs 650gb of diskspace) and runs for about 30-40 hours on our hardware. >>>>> Single thread limited in hotspot, in graal it seems to be slower in a fully threaded part. >>>>> >>>>> I can also give two different sampler profiles that might point to where the problem lies. >>>>> >>>>> If you have some kind of tutorial to retrieve the assembly from the above section I would be interested in helping out that way as well. >>>>> >>>>> I hope that this kind of feedback is useful and that I can make it actionable for you. >>>>> >>>>> The hardware is 24 cores of AMD Opteron 6348. With 256GB of ram, of which 16GB was set aside for this JVMs heap. If you are curious the app is www.uniprot.org. >>>>> >>>>> Regards, >>>>> Jerven > From bahram.yarahmadi at gmail.com Tue Jun 14 08:44:46 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Tue, 14 Jun 2016 13:14:46 +0430 Subject: Building a graph manually Message-ID: Hello guys, I want to build a graph manually but when I want to add an invokeNode to the graph I get an error this is my code : StructuredGraph graph = new StructuredGraph(AllowAssumptions.YES); ReturnNode returnNode = graph.add(new ReturnNode(null)); ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), StampFactory.intValue()); ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), StampFactory.intValue()); ValueNode[] valueNodes = new ValueNode[2]; valueNodes[0] = valueNode1; valueNodes[1] = valueNode2; ResolvedJavaMethod method = findMethod(AA.class, "SubInt"); MethodCallTargetNode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, method, valueNodes, StampFactory.forDeclaredType(null, method.getSignature().getReturnType(null), false), null)); InvokeNode ink = graph.add(new InvokeNode(callTarget, BytecodeFrame.UNWIND_BCI)); graph.start().setNext(ink); ink.setNext(returnNode); Debug.dump(Debug.BASIC_LOG_LEVEL, graph, "Graph"); and my SubInt method is public static void SubInt(int a, int b) { System.out.println("///"); } but when I try to test with inittest I get this error : testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) java.lang.AssertionError: Input not alive at com.oracle.graal.graph.NodeClass.registerAtInputsAsUsageHelper(NodeClass.java:1257) at com.oracle.graal.graph.NodeClass.registerAtInputsAsUsage(NodeClass.java:1245) at com.oracle.graal.graph.Node.initialize(Node.java:593) at com.oracle.graal.graph.Graph.addHelper(Graph.java:446) at com.oracle.graal.graph.Graph.add(Graph.java:398) at com.oracle.graal.compiler.test.tutorial.GraalTutorial.testPrintBytecodes(GraalTutorial.java:278) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) Thanks again Bahram, From christian.wimmer at oracle.com Tue Jun 14 18:24:53 2016 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Tue, 14 Jun 2016 11:24:53 -0700 Subject: Building a graph manually In-Reply-To: References: Message-ID: <57604BF5.6080102@oracle.com> Seems like you are not adding the ConstantNode to the graph. ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), StampFactory.intValue()); should be ValueNode valueNode1 = graph.unique(new ConstantNode(JavaConstant.forInt(154), StampFactory.intValue())); Since constants are floating nodes, you need to use unique() instead of add() - but they still need to be made part of the graph. -Christian On 06/14/2016 01:44 AM, Bahram Yarahmadi wrote: > Hello guys, > > I want to build a graph manually but when I want to add an invokeNode to > the graph I get an error > this is my code : > StructuredGraph graph = new StructuredGraph(AllowAssumptions.YES); > ReturnNode returnNode = graph.add(new ReturnNode(null)); > ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), > StampFactory.intValue()); > ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), > StampFactory.intValue()); > ValueNode[] valueNodes = new ValueNode[2]; > valueNodes[0] = valueNode1; > valueNodes[1] = valueNode2; > ResolvedJavaMethod method = findMethod(AA.class, "SubInt"); > MethodCallTargetNode callTarget = graph.add(new > MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, > method, valueNodes, > StampFactory.forDeclaredType(null, > method.getSignature().getReturnType(null), false), null)); > InvokeNode ink = graph.add(new InvokeNode(callTarget, > BytecodeFrame.UNWIND_BCI)); > graph.start().setNext(ink); > ink.setNext(returnNode); > Debug.dump(Debug.BASIC_LOG_LEVEL, graph, "Graph"); > and my SubInt method is > > public static void SubInt(int a, int b) { > System.out.println("///"); > } > but when I try to test with inittest I get this error : > testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > java.lang.AssertionError: Input not alive > at > com.oracle.graal.graph.NodeClass.registerAtInputsAsUsageHelper(NodeClass.java:1257) > at > com.oracle.graal.graph.NodeClass.registerAtInputsAsUsage(NodeClass.java:1245) > at com.oracle.graal.graph.Node.initialize(Node.java:593) > at com.oracle.graal.graph.Graph.addHelper(Graph.java:446) > at com.oracle.graal.graph.Graph.add(Graph.java:398) > at > com.oracle.graal.compiler.test.tutorial.GraalTutorial.testPrintBytecodes(GraalTutorial.java:278) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > > > > Thanks again > > Bahram, > From bahram.yarahmadi at gmail.com Wed Jun 15 15:33:58 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Wed, 15 Jun 2016 20:03:58 +0430 Subject: Building a graph manually In-Reply-To: <57604BF5.6080102@oracle.com> References: <57604BF5.6080102@oracle.com> Message-ID: Thanks for your help christian ,It worked I want to modify the graph an insert my own InvokeNode with MethodCallTargetNode to graph but according to the post from this mailing list (http://mail.openjdk.java.net/pipermail/graal-dev/2013-July/000650.html" it was impossible.Is it possible after about three years ?! This is my code,I get an error when I try to run it with unittest StructuredGraph graph = new StructuredGraph(AllowAssumptions.YES); ReturnNode returnNode = graph.add(new ReturnNode(null)); ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), StampFactory.intValue()); ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), StampFactory.intValue()); ValueNode[] valueNodes = new ValueNode[2]; valueNodes[0] = valueNode1; valueNodes[1] = valueNode2; graph.addWithoutUnique(valueNode1); graph.addWithoutUnique(valueNode2); ResolvedJavaMethod method = findMethod(Student.class, "SubInt"); MethodCallTargetNode callTarget = graph.add(new MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, method, valueNodes, StampFactory.forDeclaredType(null, method.getSignature().getReturnType(null), false), null)); InvokeNode ink = graph.add(new InvokeNode(callTarget, BytecodeFrame.UNWIND_BCI)); graph.start().setNext(ink); ink.setNext(returnNode); OptimisticOptimizations optimisticOpts = OptimisticOptimizations.ALL; PhaseSuite graphBuilderSuite = backend.getSuites().getDefaultGraphBuilderSuite(); Suites suites = backend.getSuites().getDefaultSuites(); LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); ProfilingInfo profilingInfo = graph.getProfilingInfo(method); CompilationResult compilationResult = new CompilationResult(); CompilationResultBuilderFactory factory = CompilationResultBuilderFactory.Default; GraalCompiler.compileGraph(graph, method, providers, backend, graphBuilderSuite, optimisticOpts, profilingInfo, suites, lirSuites, compilationResult, factory); CompiledCode compiledCode = backend.createCompiledCode(method, compilationResult); InstalledCode installedCode = codeCache.addCode(method, compiledCode, null, null); try { installedCode.executeVarargs(); } catch (InvalidInstalledCodeException e) { e.printStackTrace(); } and by the way,Is it a correct way to compile a graph ? or It is better to write my own compilation phases Thanks again Regards On Tue, Jun 14, 2016 at 10:54 PM, Christian Wimmer < christian.wimmer at oracle.com> wrote: > Seems like you are not adding the ConstantNode to the graph. > > ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), > StampFactory.intValue()); > > should be > > ValueNode valueNode1 = graph.unique(new > ConstantNode(JavaConstant.forInt(154), StampFactory.intValue())); > > Since constants are floating nodes, you need to use unique() instead of > add() - but they still need to be made part of the graph. > > -Christian > > > > On 06/14/2016 01:44 AM, Bahram Yarahmadi wrote: > >> Hello guys, >> >> I want to build a graph manually but when I want to add an invokeNode to >> the graph I get an error >> this is my code : >> StructuredGraph graph = new >> StructuredGraph(AllowAssumptions.YES); >> ReturnNode returnNode = graph.add(new ReturnNode(null)); >> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), >> StampFactory.intValue()); >> ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), >> StampFactory.intValue()); >> ValueNode[] valueNodes = new ValueNode[2]; >> valueNodes[0] = valueNode1; >> valueNodes[1] = valueNode2; >> ResolvedJavaMethod method = findMethod(AA.class, "SubInt"); >> MethodCallTargetNode callTarget = graph.add(new >> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, >> method, valueNodes, >> StampFactory.forDeclaredType(null, >> method.getSignature().getReturnType(null), false), null)); >> InvokeNode ink = graph.add(new InvokeNode(callTarget, >> BytecodeFrame.UNWIND_BCI)); >> graph.start().setNext(ink); >> ink.setNext(returnNode); >> Debug.dump(Debug.BASIC_LOG_LEVEL, graph, "Graph"); >> and my SubInt method is >> >> public static void SubInt(int a, int b) { >> System.out.println("///"); >> } >> but when I try to test with inittest I get this error : >> testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) >> java.lang.AssertionError: Input not alive >> at >> >> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsageHelper(NodeClass.java:1257) >> at >> >> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsage(NodeClass.java:1245) >> at com.oracle.graal.graph.Node.initialize(Node.java:593) >> at com.oracle.graal.graph.Graph.addHelper(Graph.java:446) >> at com.oracle.graal.graph.Graph.add(Graph.java:398) >> at >> >> com.oracle.graal.compiler.test.tutorial.GraalTutorial.testPrintBytecodes(GraalTutorial.java:278) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> >> >> >> Thanks again >> >> Bahram, >> >> From bahram.yarahmadi at gmail.com Wed Jun 15 15:35:49 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Wed, 15 Jun 2016 20:05:49 +0430 Subject: Building a graph manually In-Reply-To: References: <57604BF5.6080102@oracle.com> Message-ID: And this is the error that I always get [thread:1] scope: main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException Exception occurred in scope: main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException Context obj java.lang.NullPointerException Context obj com.oracle.graal.phases.common.CanonicalizerPhase at 77556fd Context obj com.oracle.graal.compiler.phases.HighTier at 368239c8 Context obj StructuredGraph:1 Context obj jdk.vm.ci.hotspot.HotSpotCodeCacheProvider at 3b192d32 E testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) java.lang.NullPointerException at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) at com.oracle.graal.nodes.java.MethodCallTargetNode.simplify(MethodCallTargetNode.java:165) at com.oracle.graal.phases.common.CanonicalizerPhase$Instance.tryCanonicalize(CanonicalizerPhase.java:308) at com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processNode(CanonicalizerPhase.java:225) at com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processWorkSet(CanonicalizerPhase.java:210) at com.oracle.graal.phases.common.CanonicalizerPhase$Instance.run(CanonicalizerPhase.java:180) at com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:104) at com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:1) at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:116) at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) at com.oracle.graal.compiler.GraalCompiler.emitFrontEnd(GraalCompiler.java:200) On Wed, Jun 15, 2016 at 8:03 PM, Bahram Yarahmadi < bahram.yarahmadi at gmail.com> wrote: > Thanks for your help christian ,It worked > I want to modify the graph an insert my own InvokeNode with > MethodCallTargetNode to graph but according to the post from this mailing > list ( > http://mail.openjdk.java.net/pipermail/graal-dev/2013-July/000650.html" > it was impossible.Is it possible after about three years ?! > This is my code,I get an error when I try to run it with unittest > StructuredGraph graph = new StructuredGraph(AllowAssumptions.YES); > ReturnNode returnNode = graph.add(new ReturnNode(null)); > ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), > StampFactory.intValue()); > ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), > StampFactory.intValue()); > ValueNode[] valueNodes = new ValueNode[2]; > valueNodes[0] = valueNode1; > valueNodes[1] = valueNode2; > graph.addWithoutUnique(valueNode1); > graph.addWithoutUnique(valueNode2); > ResolvedJavaMethod method = findMethod(Student.class, "SubInt"); > MethodCallTargetNode callTarget = graph.add(new > MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, > method, valueNodes, StampFactory.forDeclaredType(null, > method.getSignature().getReturnType(null), false), null)); > InvokeNode ink = graph.add(new InvokeNode(callTarget, > BytecodeFrame.UNWIND_BCI)); > graph.start().setNext(ink); > ink.setNext(returnNode); > OptimisticOptimizations optimisticOpts = > OptimisticOptimizations.ALL; > PhaseSuite graphBuilderSuite = > backend.getSuites().getDefaultGraphBuilderSuite(); > Suites suites = backend.getSuites().getDefaultSuites(); > LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); > ProfilingInfo profilingInfo = graph.getProfilingInfo(method); > CompilationResult compilationResult = new CompilationResult(); > CompilationResultBuilderFactory factory = > CompilationResultBuilderFactory.Default; > GraalCompiler.compileGraph(graph, method, providers, backend, > graphBuilderSuite, > optimisticOpts, profilingInfo, suites, lirSuites, > compilationResult, factory); > CompiledCode compiledCode = backend.createCompiledCode(method, > compilationResult); > InstalledCode installedCode = codeCache.addCode(method, > compiledCode, null, null); > try { > installedCode.executeVarargs(); > > } catch (InvalidInstalledCodeException e) { > > e.printStackTrace(); > } > and by the way,Is it a correct way to compile a graph ? or It is better to > write my own compilation phases > > Thanks again > > Regards > > > > > On Tue, Jun 14, 2016 at 10:54 PM, Christian Wimmer < > christian.wimmer at oracle.com> wrote: > >> Seems like you are not adding the ConstantNode to the graph. >> >> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), >> StampFactory.intValue()); >> >> should be >> >> ValueNode valueNode1 = graph.unique(new >> ConstantNode(JavaConstant.forInt(154), StampFactory.intValue())); >> >> Since constants are floating nodes, you need to use unique() instead of >> add() - but they still need to be made part of the graph. >> >> -Christian >> >> >> >> On 06/14/2016 01:44 AM, Bahram Yarahmadi wrote: >> >>> Hello guys, >>> >>> I want to build a graph manually but when I want to add an invokeNode to >>> the graph I get an error >>> this is my code : >>> StructuredGraph graph = new >>> StructuredGraph(AllowAssumptions.YES); >>> ReturnNode returnNode = graph.add(new ReturnNode(null)); >>> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), >>> StampFactory.intValue()); >>> ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), >>> StampFactory.intValue()); >>> ValueNode[] valueNodes = new ValueNode[2]; >>> valueNodes[0] = valueNode1; >>> valueNodes[1] = valueNode2; >>> ResolvedJavaMethod method = findMethod(AA.class, "SubInt"); >>> MethodCallTargetNode callTarget = graph.add(new >>> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, >>> method, valueNodes, >>> StampFactory.forDeclaredType(null, >>> method.getSignature().getReturnType(null), false), null)); >>> InvokeNode ink = graph.add(new InvokeNode(callTarget, >>> BytecodeFrame.UNWIND_BCI)); >>> graph.start().setNext(ink); >>> ink.setNext(returnNode); >>> Debug.dump(Debug.BASIC_LOG_LEVEL, graph, "Graph"); >>> and my SubInt method is >>> >>> public static void SubInt(int a, int b) { >>> System.out.println("///"); >>> } >>> but when I try to test with inittest I get this error : >>> testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) >>> java.lang.AssertionError: Input not alive >>> at >>> >>> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsageHelper(NodeClass.java:1257) >>> at >>> >>> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsage(NodeClass.java:1245) >>> at com.oracle.graal.graph.Node.initialize(Node.java:593) >>> at com.oracle.graal.graph.Graph.addHelper(Graph.java:446) >>> at com.oracle.graal.graph.Graph.add(Graph.java:398) >>> at >>> >>> com.oracle.graal.compiler.test.tutorial.GraalTutorial.testPrintBytecodes(GraalTutorial.java:278) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> >>> >>> >>> Thanks again >>> >>> Bahram, >>> >>> > From gilles.m.duboscq at oracle.com Wed Jun 15 15:51:06 2016 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Wed, 15 Jun 2016 17:51:06 +0200 Subject: Building a graph manually In-Reply-To: References: <57604BF5.6080102@oracle.com> Message-ID: <29658725-cace-0bcc-9a9b-1ef6e1d36676@oracle.com> Hi, Your InvokeNode does not seem to have a valid FrameState node. The reason why it's hard to create an InvokeNode out of the blue is that in order to install code, it has to make sense for the VM. For example, there needs to be a corresponding invoke bytecode somewhere and there needs to be a state where the VM can deoptimize to. Gilles On 15/06/16 17:35, Bahram Yarahmadi wrote: > And this is the error that I always get > [thread:1] scope: > main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException > Exception occurred in scope: > main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException > Context obj java.lang.NullPointerException > Context obj > com.oracle.graal.phases.common.CanonicalizerPhase at 77556fd > Context obj com.oracle.graal.compiler.phases.HighTier at 368239c8 > Context obj StructuredGraph:1 > Context obj jdk.vm.ci.hotspot.HotSpotCodeCacheProvider at 3b192d32 > E > testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > java.lang.NullPointerException > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > at > com.oracle.graal.nodes.java.MethodCallTargetNode.simplify(MethodCallTargetNode.java:165) > at > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.tryCanonicalize(CanonicalizerPhase.java:308) > at > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processNode(CanonicalizerPhase.java:225) > at > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processWorkSet(CanonicalizerPhase.java:210) > at > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.run(CanonicalizerPhase.java:180) > at > com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:104) > at > com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:1) > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) > at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:116) > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) > at > com.oracle.graal.compiler.GraalCompiler.emitFrontEnd(GraalCompiler.java:200) > > > On Wed, Jun 15, 2016 at 8:03 PM, Bahram Yarahmadi < > bahram.yarahmadi at gmail.com> wrote: > >> Thanks for your help christian ,It worked >> I want to modify the graph an insert my own InvokeNode with >> MethodCallTargetNode to graph but according to the post from this mailing >> list ( >> http://mail.openjdk.java.net/pipermail/graal-dev/2013-July/000650.html" >> it was impossible.Is it possible after about three years ?! >> This is my code,I get an error when I try to run it with unittest >> StructuredGraph graph = new StructuredGraph(AllowAssumptions.YES); >> ReturnNode returnNode = graph.add(new ReturnNode(null)); >> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), >> StampFactory.intValue()); >> ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), >> StampFactory.intValue());where and there needs to be a state where the VM can deoptimize to. >> ValueNode[] valueNodes = new ValueNode[2]; >> valueNodes[0] = valueNode1; >> valueNodes[1] = valueNode2; >> graph.addWithoutUnique(valueNode1); >> graph.addWithoutUnique(valueNode2); >> ResolvedJavaMethod method = findMethod(Student.class, "SubInt"); >> MethodCallTargetNode callTarget = graph.add(new >> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, >> method, valueNodes, StampFactory.forDeclaredType(null, >> method.getSignature().getReturnType(null), false), null)); >> InvokeNode ink = graph.add(new InvokeNode(callTarget, >> BytecodeFrame.UNWIND_BCI)); >> graph.start().setNext(ink); >> ink.setNext(returnNode); >> OptimisticOptimizations optimisticOpts = >> OptimisticOptimizations.ALL; >> PhaseSuite graphBuilderSuite = >> backend.getSuites().getDefaultGraphBuilderSuite(); >> Suites suites = backend.getSuites().getDefaultSuites(); >> LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); >> ProfilingInfo profilingInfo = graph.getProfilingInfo(method); >> CompilationResult compilationResult = new CompilationResult(); >> CompilationResultBuilderFactory factory = >> CompilationResultBuilderFactory.Default; >> GraalCompiler.compileGraph(graph, method, providers, backend, >> graphBuilderSuite, >> optimisticOpts, profilingInfo, suites, lirSuites, >> compilationResult, factory); >> CompiledCode compiledCode = backend.createCompiledCode(method, >> compilationResult); >> InstalledCode installedCode = codeCache.addCode(method, >> compiledCode, null, null); >> try { >> installedCode.executeVarargs(); >> >> } catch (InvalidInstalledCodeException e) { >> >> e.printStackTrace(); >> } >> and by the way,Is it a correct way to compile a graph ? or It is better to >> write my own compilation phases >> >> Thanks again >> >> Regards >> >> >> >> >> On Tue, Jun 14, 2016 at 10:54 PM, Christian Wimmer < >> christian.wimmer at oracle.com> wrote: >> >>> Seems like you are not adding the ConstantNode to the graph. >>> >>> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), >>> StampFactory.intValue()); >>> >>> should be >>> >>> ValueNode valueNode1 = graph.unique(new >>> ConstantNode(JavaConstant.forInt(154), StampFactory.intValue())); >>> >>> Since constants are floating nodes, you need to use unique() instead of >>> add() - but they still need to be made part of the graph. >>> >>> -Christian >>> >>> >>> >>> On 06/14/2016 01:44 AM, Bahram Yarahmadi wrote: >>> >>>> Hello guys, >>>> >>>> I want to build a graph manually but when I want to add an invokeNode to >>>> the graph I get an error >>>> this is my code : >>>> StructuredGraph graph = new >>>> StructuredGraph(AllowAssumptions.YES); >>>> ReturnNode returnNode = graph.add(new ReturnNode(null)); >>>> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), >>>> StampFactory.intValue()); >>>> ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), >>>> StampFactory.intValue()); >>>> ValueNode[] valueNodes = new ValueNode[2]; >>>> valueNodes[0] = valueNode1; >>>> valueNodes[1] = valueNode2; >>>> ResolvedJavaMethod method = findMethod(AA.class, "SubInt"); >>>> MethodCallTargetNode callTarget = graph.add(new >>>> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, >>>> method, valueNodes, >>>> StampFactory.forDeclaredType(null, >>>> method.getSignature().getReturnType(null), false), null)); >>>> InvokeNode ink = graph.add(new InvokeNode(callTarget, >>>> BytecodeFrame.UNWIND_BCI)); >>>> graph.start().setNext(ink); >>>> ink.setNext(returnNode); >>>> Debug.dump(Debug.BASIC_LOG_LEVEL, graph, "Graph"); >>>> and my SubInt method is >>>> >>>> public static void SubInt(int a, int b) { >>>> System.out.println("///"); >>>> } >>>> but when I try to test with inittest I get this error : >>>> testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) >>>> java.lang.AssertionError: Input not alive >>>> at >>>> >>>> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsageHelper(NodeClass.java:1257) >>>> at >>>> >>>> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsage(NodeClass.java:1245) >>>> at com.oracle.graal.graph.Node.initialize(Node.java:593) >>>> at com.oracle.graal.graph.Graph.addHelper(Graph.java:446) >>>> at com.oracle.graal.graph.Graph.add(Graph.java:398) >>>> at >>>> >>>> com.oracle.graal.compiler.test.tutorial.GraalTutorial.testPrintBytecodes(GraalTutorial.java:278) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> at >>>> >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>> >>>> >>>> >>>> Thanks again >>>> >>>> Bahram, >>>> >>>> >> From doug.simon at oracle.com Thu Jun 16 19:12:41 2016 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Jun 2016 21:12:41 +0200 Subject: Replaced jvmci suite dependency with dependency on a JVMCI JDK Message-ID: <820320C4-39E4-4838-A1A7-92EA3EFCC80D@oracle.com> The time has arrived to treat JVMCI as a frozen API. This will be the case anyway once JDK 9 is released. As such, we have removed[1] the dependency from graal-core to the jvmci suite and instead graal-core now requires JAVA_HOME to be a JVMCI enabled JDK. For JDK 9, an EA build[2] should be available within the next month that contains the remaining JVMCI API changes. For JDK 8, we will provide binaries on OTN[3]. Until the OTN binaries are available, you can build your own as follows: hg clone http://hg.openjdk.java.net/graal/graal-jvmci-8 cd graal-jvmci-8 mx --java-home /path/to/jdk8u92 build export JAVA_HOME=$(mx --java-home /path/to/jdk8u92 jdkhome) For both JDK 8 and JDK 9, a JVMCI binary enables JVMCI for hosted use as well as replacing C2 as the top-tier compiler. The -server option enables the former usage and adding -XX:+UseJVMCICompiler (additionally) enables the latter. To disable JVMCI altogether, you can specify -XX:-EnableJVMCI. From an mx perspective, the --vm and --vmbuild options have disappeared along with the jvmci suite. Note that these options changes are only related to JVMCI itself - the graal-core suite will add additional options to configure Graal as the JVMCI compiler. Of most interest is the -Djvmci.class.path.append system property which is used by the graal-core JDK (i.e., selected by `--jdk jvmci` or by having graal-core as the primary suite) to communicate the Graal jars to the VM. This allows Graal to run on the JVMCI JDK without modifying the JDK directory. -Doug [1] https://github.com/graalvm/graal-core/commit/92ab54c0f5ae640b2f7850cd43ef9b9a9b7b4718 [2] https://jdk9.java.net/download/ [3] http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html From bahram.yarahmadi at gmail.com Fri Jun 17 08:41:31 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Fri, 17 Jun 2016 13:11:31 +0430 Subject: Building a graph manually In-Reply-To: <29658725-cace-0bcc-9a9b-1ef6e1d36676@oracle.com> References: <57604BF5.6080102@oracle.com> <29658725-cace-0bcc-9a9b-1ef6e1d36676@oracle.com> Message-ID: Thanks Gilles I cannot even build the state on the fly,I think it must be a non trivial task I made some progress and now for "just some" methods , I can redirect an invoke with InliningUtil.replaceInvokeCallTarget , for instance :I can invoke method X() instead of method Y() at runtime but my target is Lambdas with stream APIs , for example: Intstream.rang(0,10).parallel.foreach(....) I modify the graph and I delete invoke#range,invoke#parallel ,invoke#foreach from cfg I made a pure control flow which only contains 285377351.linkToTargetMethod as an invoke node which is static but when I want to redirect this method I get this Error testGraphKitTool(com.oracle.graal.compiler.test.tutorial.GraalTutorial) java.lang.NullPointerException at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) at com.oracle.graal.compiler.test.tutorial.GraalTutorial.testGraphKitTool(GraalTutorial.java:449) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at org.junit.runner.JUnitCore.run(JUnitCore.java:138) at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:167) Time: 0.249 There was 1 failure: 1) testGraphKitTool(com.oracle.graal.compiler.test.tutorial.GraalTutorial) java.lang.NullPointerException at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) at com.oracle.graal.compiler.test.tutorial.GraalTutorial.testGraphKitTool(GraalTutorial.java:449) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at org.junit.runner.JUnitCore.run(JUnitCore.java:138) at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:167) What is the difference between these two scenarios?? Can I Interpret my graph instead of compile in graal in this case ?? Thanks Bahram On Wed, Jun 15, 2016 at 8:21 PM, Gilles Duboscq wrote: > Hi, > > Your InvokeNode does not seem to have a valid FrameState node. > > The reason why it's hard to create an InvokeNode out of the blue is that > in order to install code, it has to make sense for the VM. > For example, there needs to be a corresponding invoke bytecode somewhere > and there needs to be a state where the VM can deoptimize to. > > Gilles > > On 15/06/16 17:35, Bahram Yarahmadi wrote: > > And this is the error that I always get > > [thread:1] scope: > > > main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException > > Exception occurred in scope: > > > main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException > > Context obj java.lang.NullPointerException > > Context obj > > com.oracle.graal.phases.common.CanonicalizerPhase at 77556fd > > Context obj > com.oracle.graal.compiler.phases.HighTier at 368239c8 > > Context obj StructuredGraph:1 > > Context obj > jdk.vm.ci.hotspot.HotSpotCodeCacheProvider at 3b192d32 > > E > > testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > > java.lang.NullPointerException > > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > > at > > > com.oracle.graal.nodes.java.MethodCallTargetNode.simplify(MethodCallTargetNode.java:165) > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.tryCanonicalize(CanonicalizerPhase.java:308) > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processNode(CanonicalizerPhase.java:225) > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processWorkSet(CanonicalizerPhase.java:210) > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.run(CanonicalizerPhase.java:180) > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:104) > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:1) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) > > at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:116) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) > > at > > > com.oracle.graal.compiler.GraalCompiler.emitFrontEnd(GraalCompiler.java:200) > > > > > > On Wed, Jun 15, 2016 at 8:03 PM, Bahram Yarahmadi < > > bahram.yarahmadi at gmail.com> wrote: > > > >> Thanks for your help christian ,It worked > >> I want to modify the graph an insert my own InvokeNode with > >> MethodCallTargetNode to graph but according to the post from this > mailing > >> list ( > >> http://mail.openjdk.java.net/pipermail/graal-dev/2013-July/000650.html" > >> it was impossible.Is it possible after about three years ?! > >> This is my code,I get an error when I try to run it with unittest > >> StructuredGraph graph = new > StructuredGraph(AllowAssumptions.YES); > >> ReturnNode returnNode = graph.add(new ReturnNode(null)); > >> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), > >> StampFactory.intValue()); > >> ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), > >> StampFactory.intValue());where and there needs to be a state where the > VM can deoptimize to. > >> ValueNode[] valueNodes = new ValueNode[2]; > >> valueNodes[0] = valueNode1; > >> valueNodes[1] = valueNode2; > >> graph.addWithoutUnique(valueNode1); > >> graph.addWithoutUnique(valueNode2); > >> ResolvedJavaMethod method = findMethod(Student.class, "SubInt"); > >> MethodCallTargetNode callTarget = graph.add(new > >> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, > >> method, valueNodes, StampFactory.forDeclaredType(null, > >> method.getSignature().getReturnType(null), false), null)); > >> InvokeNode ink = graph.add(new InvokeNode(callTarget, > >> BytecodeFrame.UNWIND_BCI)); > >> graph.start().setNext(ink); > >> ink.setNext(returnNode); > >> OptimisticOptimizations optimisticOpts = > >> OptimisticOptimizations.ALL; > >> PhaseSuite graphBuilderSuite = > >> backend.getSuites().getDefaultGraphBuilderSuite(); > >> Suites suites = backend.getSuites().getDefaultSuites(); > >> LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); > >> ProfilingInfo profilingInfo = graph.getProfilingInfo(method); > >> CompilationResult compilationResult = new CompilationResult(); > >> CompilationResultBuilderFactory factory = > >> CompilationResultBuilderFactory.Default; > >> GraalCompiler.compileGraph(graph, method, providers, backend, > >> graphBuilderSuite, > >> optimisticOpts, profilingInfo, suites, lirSuites, > >> compilationResult, factory); > >> CompiledCode compiledCode = backend.createCompiledCode(method, > >> compilationResult); > >> InstalledCode installedCode = codeCache.addCode(method, > >> compiledCode, null, null); > >> try { > >> installedCode.executeVarargs(); > >> > >> } catch (InvalidInstalledCodeException e) { > >> > >> e.printStackTrace(); > >> } > >> and by the way,Is it a correct way to compile a graph ? or It is better > to > >> write my own compilation phases > >> > >> Thanks again > >> > >> Regards > >> > >> > >> > >> > >> On Tue, Jun 14, 2016 at 10:54 PM, Christian Wimmer < > >> christian.wimmer at oracle.com> wrote: > >> > >>> Seems like you are not adding the ConstantNode to the graph. > >>> > >>> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), > >>> StampFactory.intValue()); > >>> > >>> should be > >>> > >>> ValueNode valueNode1 = graph.unique(new > >>> ConstantNode(JavaConstant.forInt(154), StampFactory.intValue())); > >>> > >>> Since constants are floating nodes, you need to use unique() instead of > >>> add() - but they still need to be made part of the graph. > >>> > >>> -Christian > >>> > >>> > >>> > >>> On 06/14/2016 01:44 AM, Bahram Yarahmadi wrote: > >>> > >>>> Hello guys, > >>>> > >>>> I want to build a graph manually but when I want to add an invokeNode > to > >>>> the graph I get an error > >>>> this is my code : > >>>> StructuredGraph graph = new > >>>> StructuredGraph(AllowAssumptions.YES); > >>>> ReturnNode returnNode = graph.add(new ReturnNode(null)); > >>>> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), > >>>> StampFactory.intValue()); > >>>> ValueNode valueNode2 = new > ConstantNode(JavaConstant.forInt(25), > >>>> StampFactory.intValue()); > >>>> ValueNode[] valueNodes = new ValueNode[2]; > >>>> valueNodes[0] = valueNode1; > >>>> valueNodes[1] = valueNode2; > >>>> ResolvedJavaMethod method = findMethod(AA.class, "SubInt"); > >>>> MethodCallTargetNode callTarget = graph.add(new > >>>> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, > >>>> method, valueNodes, > >>>> StampFactory.forDeclaredType(null, > >>>> method.getSignature().getReturnType(null), false), null)); > >>>> InvokeNode ink = graph.add(new InvokeNode(callTarget, > >>>> BytecodeFrame.UNWIND_BCI)); > >>>> graph.start().setNext(ink); > >>>> ink.setNext(returnNode); > >>>> Debug.dump(Debug.BASIC_LOG_LEVEL, graph, "Graph"); > >>>> and my SubInt method is > >>>> > >>>> public static void SubInt(int a, int b) { > >>>> System.out.println("///"); > >>>> } > >>>> but when I try to test with inittest I get this error : > >>>> > testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > >>>> java.lang.AssertionError: Input not alive > >>>> at > >>>> > >>>> > com.oracle.graal.graph.NodeClass.registerAtInputsAsUsageHelper(NodeClass.java:1257) > >>>> at > >>>> > >>>> > com.oracle.graal.graph.NodeClass.registerAtInputsAsUsage(NodeClass.java:1245) > >>>> at com.oracle.graal.graph.Node.initialize(Node.java:593) > >>>> at com.oracle.graal.graph.Graph.addHelper(Graph.java:446) > >>>> at com.oracle.graal.graph.Graph.add(Graph.java:398) > >>>> at > >>>> > >>>> > com.oracle.graal.compiler.test.tutorial.GraalTutorial.testPrintBytecodes(GraalTutorial.java:278) > >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >>>> at > >>>> > >>>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >>>> at > >>>> > >>>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >>>> at java.lang.reflect.Method.invoke(Method.java:498) > >>>> > >>>> > >>>> > >>>> Thanks again > >>>> > >>>> Bahram, > >>>> > >>>> > >> > From bahram.yarahmadi at gmail.com Sat Jun 18 08:14:22 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Sat, 18 Jun 2016 12:44:22 +0430 Subject: Building a graph manually In-Reply-To: References: <57604BF5.6080102@oracle.com> <29658725-cace-0bcc-9a9b-1ef6e1d36676@oracle.com> Message-ID: Hi guys Does anyone here know any proper bytecode instrumentation which I can use it with graal !? On Fri, Jun 17, 2016 at 1:11 PM, Bahram Yarahmadi < bahram.yarahmadi at gmail.com> wrote: > Thanks Gilles > I cannot even build the state on the fly,I think it must be a non trivial > task > I made some progress and now for "just some" methods , I can redirect an > invoke with InliningUtil.replaceInvokeCallTarget , > for instance :I can invoke method X() instead of method Y() at runtime > but my target is Lambdas with stream APIs , > for example: > Intstream.rang(0,10).parallel.foreach(....) > I modify the graph and I delete invoke#range,invoke#parallel > ,invoke#foreach from cfg > I made a pure control flow which only > contains 285377351.linkToTargetMethod as an invoke node which is static but > when I want to redirect this method I get this Error > testGraphKitTool(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > java.lang.NullPointerException > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > at > com.oracle.graal.compiler.test.tutorial.GraalTutorial.testGraphKitTool(GraalTutorial.java:449) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:167) > > Time: 0.249 > There was 1 failure: > 1) testGraphKitTool(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > java.lang.NullPointerException > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > at > com.oracle.graal.compiler.test.tutorial.GraalTutorial.testGraphKitTool(GraalTutorial.java:449) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:167) > > > What is the difference between these two scenarios?? > Can I Interpret my graph instead of compile in graal in this case ?? > > Thanks > > Bahram > > On Wed, Jun 15, 2016 at 8:21 PM, Gilles Duboscq < > gilles.m.duboscq at oracle.com> wrote: > >> Hi, >> >> Your InvokeNode does not seem to have a valid FrameState node. >> >> The reason why it's hard to create an InvokeNode out of the blue is that >> in order to install code, it has to make sense for the VM. >> For example, there needs to be a corresponding invoke bytecode somewhere >> and there needs to be a state where the VM can deoptimize to. >> >> Gilles >> >> On 15/06/16 17:35, Bahram Yarahmadi wrote: >> > And this is the error that I always get >> > [thread:1] scope: >> > >> main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException >> > Exception occurred in scope: >> > >> main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException >> > Context obj java.lang.NullPointerException >> > Context obj >> > com.oracle.graal.phases.common.CanonicalizerPhase at 77556fd >> > Context obj >> com.oracle.graal.compiler.phases.HighTier at 368239c8 >> > Context obj StructuredGraph:1 >> > Context obj >> jdk.vm.ci.hotspot.HotSpotCodeCacheProvider at 3b192d32 >> > E >> > >> testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) >> > java.lang.NullPointerException >> > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) >> > at >> > >> com.oracle.graal.nodes.java.MethodCallTargetNode.simplify(MethodCallTargetNode.java:165) >> > at >> > >> com.oracle.graal.phases.common.CanonicalizerPhase$Instance.tryCanonicalize(CanonicalizerPhase.java:308) >> > at >> > >> com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processNode(CanonicalizerPhase.java:225) >> > at >> > >> com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processWorkSet(CanonicalizerPhase.java:210) >> > at >> > >> com.oracle.graal.phases.common.CanonicalizerPhase$Instance.run(CanonicalizerPhase.java:180) >> > at >> > >> com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:104) >> > at >> > >> com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:1) >> > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) >> > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) >> > at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:116) >> > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) >> > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) >> > at >> > >> com.oracle.graal.compiler.GraalCompiler.emitFrontEnd(GraalCompiler.java:200) >> > >> > >> > On Wed, Jun 15, 2016 at 8:03 PM, Bahram Yarahmadi < >> > bahram.yarahmadi at gmail.com> wrote: >> > >> >> Thanks for your help christian ,It worked >> >> I want to modify the graph an insert my own InvokeNode with >> >> MethodCallTargetNode to graph but according to the post from this >> mailing >> >> list ( >> >> http://mail.openjdk.java.net/pipermail/graal-dev/2013-July/000650.html >> " >> >> it was impossible.Is it possible after about three years ?! >> >> This is my code,I get an error when I try to run it with unittest >> >> StructuredGraph graph = new >> StructuredGraph(AllowAssumptions.YES); >> >> ReturnNode returnNode = graph.add(new ReturnNode(null)); >> >> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), >> >> StampFactory.intValue()); >> >> ValueNode valueNode2 = new >> ConstantNode(JavaConstant.forInt(25), >> >> StampFactory.intValue());where and there needs to be a state where the >> VM can deoptimize to. >> >> ValueNode[] valueNodes = new ValueNode[2]; >> >> valueNodes[0] = valueNode1; >> >> valueNodes[1] = valueNode2; >> >> graph.addWithoutUnique(valueNode1); >> >> graph.addWithoutUnique(valueNode2); >> >> ResolvedJavaMethod method = findMethod(Student.class, "SubInt"); >> >> MethodCallTargetNode callTarget = graph.add(new >> >> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, >> >> method, valueNodes, StampFactory.forDeclaredType(null, >> >> method.getSignature().getReturnType(null), false), null)); >> >> InvokeNode ink = graph.add(new InvokeNode(callTarget, >> >> BytecodeFrame.UNWIND_BCI)); >> >> graph.start().setNext(ink); >> >> ink.setNext(returnNode); >> >> OptimisticOptimizations optimisticOpts = >> >> OptimisticOptimizations.ALL; >> >> PhaseSuite graphBuilderSuite = >> >> backend.getSuites().getDefaultGraphBuilderSuite(); >> >> Suites suites = backend.getSuites().getDefaultSuites(); >> >> LIRSuites lirSuites = >> backend.getSuites().getDefaultLIRSuites(); >> >> ProfilingInfo profilingInfo = graph.getProfilingInfo(method); >> >> CompilationResult compilationResult = new CompilationResult(); >> >> CompilationResultBuilderFactory factory = >> >> CompilationResultBuilderFactory.Default; >> >> GraalCompiler.compileGraph(graph, method, providers, backend, >> >> graphBuilderSuite, >> >> optimisticOpts, profilingInfo, suites, lirSuites, >> >> compilationResult, factory); >> >> CompiledCode compiledCode = backend.createCompiledCode(method, >> >> compilationResult); >> >> InstalledCode installedCode = codeCache.addCode(method, >> >> compiledCode, null, null); >> >> try { >> >> installedCode.executeVarargs(); >> >> >> >> } catch (InvalidInstalledCodeException e) { >> >> >> >> e.printStackTrace(); >> >> } >> >> and by the way,Is it a correct way to compile a graph ? or It is >> better to >> >> write my own compilation phases >> >> >> >> Thanks again >> >> >> >> Regards >> >> >> >> >> >> >> >> >> >> On Tue, Jun 14, 2016 at 10:54 PM, Christian Wimmer < >> >> christian.wimmer at oracle.com> wrote: >> >> >> >>> Seems like you are not adding the ConstantNode to the graph. >> >>> >> >>> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), >> >>> StampFactory.intValue()); >> >>> >> >>> should be >> >>> >> >>> ValueNode valueNode1 = graph.unique(new >> >>> ConstantNode(JavaConstant.forInt(154), StampFactory.intValue())); >> >>> >> >>> Since constants are floating nodes, you need to use unique() instead >> of >> >>> add() - but they still need to be made part of the graph. >> >>> >> >>> -Christian >> >>> >> >>> >> >>> >> >>> On 06/14/2016 01:44 AM, Bahram Yarahmadi wrote: >> >>> >> >>>> Hello guys, >> >>>> >> >>>> I want to build a graph manually but when I want to add an >> invokeNode to >> >>>> the graph I get an error >> >>>> this is my code : >> >>>> StructuredGraph graph = new >> >>>> StructuredGraph(AllowAssumptions.YES); >> >>>> ReturnNode returnNode = graph.add(new ReturnNode(null)); >> >>>> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), >> >>>> StampFactory.intValue()); >> >>>> ValueNode valueNode2 = new >> ConstantNode(JavaConstant.forInt(25), >> >>>> StampFactory.intValue()); >> >>>> ValueNode[] valueNodes = new ValueNode[2]; >> >>>> valueNodes[0] = valueNode1; >> >>>> valueNodes[1] = valueNode2; >> >>>> ResolvedJavaMethod method = findMethod(AA.class, "SubInt"); >> >>>> MethodCallTargetNode callTarget = graph.add(new >> >>>> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, >> >>>> method, valueNodes, >> >>>> StampFactory.forDeclaredType(null, >> >>>> method.getSignature().getReturnType(null), false), null)); >> >>>> InvokeNode ink = graph.add(new InvokeNode(callTarget, >> >>>> BytecodeFrame.UNWIND_BCI)); >> >>>> graph.start().setNext(ink); >> >>>> ink.setNext(returnNode); >> >>>> Debug.dump(Debug.BASIC_LOG_LEVEL, graph, "Graph"); >> >>>> and my SubInt method is >> >>>> >> >>>> public static void SubInt(int a, int b) { >> >>>> System.out.println("///"); >> >>>> } >> >>>> but when I try to test with inittest I get this error : >> >>>> >> testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) >> >>>> java.lang.AssertionError: Input not alive >> >>>> at >> >>>> >> >>>> >> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsageHelper(NodeClass.java:1257) >> >>>> at >> >>>> >> >>>> >> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsage(NodeClass.java:1245) >> >>>> at com.oracle.graal.graph.Node.initialize(Node.java:593) >> >>>> at com.oracle.graal.graph.Graph.addHelper(Graph.java:446) >> >>>> at com.oracle.graal.graph.Graph.add(Graph.java:398) >> >>>> at >> >>>> >> >>>> >> com.oracle.graal.compiler.test.tutorial.GraalTutorial.testPrintBytecodes(GraalTutorial.java:278) >> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >>>> at >> >>>> >> >>>> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >>>> at >> >>>> >> >>>> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >>>> at java.lang.reflect.Method.invoke(Method.java:498) >> >>>> >> >>>> >> >>>> >> >>>> Thanks again >> >>>> >> >>>> Bahram, >> >>>> >> >>>> >> >> >> > > From bahram.yarahmadi at gmail.com Sun Jun 19 10:19:46 2016 From: bahram.yarahmadi at gmail.com (Bahram Yarahmadi) Date: Sun, 19 Jun 2016 14:49:46 +0430 Subject: linkToTargetMethod Message-ID: Hello guys I want to run Lambdas with stream APIs on GPUs,I have developed a backend for graal Jit compiler which generates OpenCL C from graal IR (lamda$xx at runtime) I have a problem with my OpenCL C host code which must be somewhere on cfg . IntStream.rang(0,10).parallel.forEach(i-//); there are at least 4 InvokeNodes in Graal IR which are Intstream.range IntStream.parallel 344560770.linkToTargetMethod and IntStream.ForEach ,I omited 3 of them which are Intstream.range IntStream.parallel and IntStream.ForEach and then tried to redirect 344560770.linkToTargetMethod to a method which contains my openCL C host code but everytime I attempts I get an error ,I think the problem is related to framestates and bytecode index .... what should I do in order to redirect this method ? the methodCallTarget of this mehod has an constant argument which is DirectMethodHandle at 559450121 Regards Bahram From jaroslav.tulach at oracle.com Mon Jun 20 07:13:58 2016 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 20 Jun 2016 09:13:58 +0200 Subject: Use Builder to construct your source was: truffle-api-changes #396 In-Reply-To: <394431934.103.1466351082245@c8ffaf347c3f> References: <1993738883.102.1466154885297@c8ffaf347c3f> <394431934.103.1466351082245@c8ffaf347c3f> Message-ID: <1466408746.vs2z1kZeZl@pracovni> Hi. We are moving towards builder-like style to build an instance of Source. Use: Source.newBuilder(something). name(something). mimeType(something). build(); When working on this change I learned one[1] or two[2] things about builders. -jt [1] http://wiki.apidesign.org/wiki/ChameleonBuilder [2] http://wiki.apidesign.org/wiki/ResistingBuilder > Added Classes > ------------- > > com.oracle.truffle.api.source.MissingMIMETypeException > com.oracle.truffle.api.source.MissingNameException > com.oracle.truffle.api.source.Source$Builder > > Added Nested Classes > -------------------- > > com.oracle.truffle.api.source.Source: inner public final > com.oracle.truffle.api.source.Source$Builder > > Added Methods > ------------- > > com.oracle.truffle.api.source.Source: method public boolean > com.oracle.truffle.api.source.Source.isInternal() > com.oracle.truffle.api.source.Source: method public static > com.oracle.truffle.api.source.Source$Builder > com.oracle.truffle.api.source.Source.newBuilder(java.io.File) > com.oracle.truffle.api.source.Source: method public static > com.oracle.truffle.api.source.Source$Builder > com.oracle.truffle.api.source.Source.newBuilder(java.io.Reader) > com.oracle.truffle.api.source.Source: method public static > com.oracle.truffle.api.source.Source$Builder > com.oracle.truffle.api.source.Source.newBuilder(java.lang.String) > com.oracle.truffle.api.source.Source: method public static > com.oracle.truffle.api.source.Source$Builder > com.oracle.truffle.api.source.Source.newBuilder(java.net.URL) > > Added Annotations > ----------------- > > com.oracle.truffle.api.source.Source.fromFileName: anno 0 > java.lang.Deprecated() com.oracle.truffle.api.source.Source.fromFileName: > anno 0 java.lang.Deprecated() > com.oracle.truffle.api.source.Source.fromFileName: anno 0 > java.lang.Deprecated() com.oracle.truffle.api.source.Source.fromReader: > anno 0 java.lang.Deprecated() > com.oracle.truffle.api.source.Source.fromText: anno 0 > java.lang.Deprecated() com.oracle.truffle.api.source.Source.fromURL: > anno 0 java.lang.Deprecated() > com.oracle.truffle.api.source.Source.getShortName: anno 0 > java.lang.Deprecated() com.oracle.truffle.api.source.Source.withMimeType: > anno 0 java.lang.Deprecated() From gilles.m.duboscq at oracle.com Mon Jun 20 09:49:58 2016 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Mon, 20 Jun 2016 11:49:58 +0200 Subject: Building a graph manually In-Reply-To: References: <57604BF5.6080102@oracle.com> <29658725-cace-0bcc-9a9b-1ef6e1d36676@oracle.com> Message-ID: Hi, Any bytecode instrumentation framework should work with Graal. Maybe you could have a look at DiSL [1] for example. Gilles [1] https://disl.ow2.org/bin/view/Main/ On 18/06/16 10:14, Bahram Yarahmadi wrote: > Hi guys > Does anyone here know any proper bytecode instrumentation which I can use it with graal !? > > On Fri, Jun 17, 2016 at 1:11 PM, Bahram Yarahmadi > wrote: > > Thanks Gilles > I cannot even build the state on the fly,I think it must be a non trivial task > I made some progress and now for "just some" methods , I can redirect an invoke with InliningUtil.replaceInvokeCallTarget , > for instance :I can invoke method X() instead of method Y() at runtime > but my target is Lambdas with stream APIs , > for example: > Intstream.rang(0,10).parallel.foreach(....) > I modify the graph and I delete invoke#range,invoke#parallel ,invoke#foreach from cfg > I made a pure control flow which only contains 285377351.linkToTargetMethod as an invoke node which is static but when I want to redirect this method I get this Error > testGraphKitTool(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > java.lang.NullPointerException > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > at com.oracle.graal.compiler.test.tutorial.GraalTutorial.testGraphKitTool(GraalTutorial.java:449) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:167) > > Time: 0.249 > There was 1 failure: > 1) testGraphKitTool(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > java.lang.NullPointerException > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > at com.oracle.graal.compiler.test.tutorial.GraalTutorial.testGraphKitTool(GraalTutorial.java:449) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:167) > > > What is the difference between these two scenarios?? > Can I Interpret my graph instead of compile in graal in this case ?? > > Thanks > > Bahram > > On Wed, Jun 15, 2016 at 8:21 PM, Gilles Duboscq > wrote: > > Hi, > > Your InvokeNode does not seem to have a valid FrameState node. > > The reason why it's hard to create an InvokeNode out of the blue is that in order to install code, it has to make sense for the VM. > For example, there needs to be a corresponding invoke bytecode somewhere and there needs to be a state where the VM can deoptimize to. > > Gilles > > On 15/06/16 17:35, Bahram Yarahmadi wrote: > > And this is the error that I always get > > [thread:1] scope: > > main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException > > Exception occurred in scope: > > main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException > > Context obj java.lang.NullPointerException > > Context obj > > com.oracle.graal.phases.common.CanonicalizerPhase at 77556fd > > Context obj com.oracle.graal.compiler.phases.HighTier at 368239c8 > > Context obj StructuredGraph:1 > > Context obj jdk.vm.ci.hotspot.HotSpotCodeCacheProvider at 3b192d32 > > E > > testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > > java.lang.NullPointerException > > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > > at > > com.oracle.graal.nodes.java.MethodCallTargetNode.simplify(MethodCallTargetNode.java:165) > > at > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.tryCanonicalize(CanonicalizerPhase.java:308) > > at > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processNode(CanonicalizerPhase.java:225) > > at > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processWorkSet(CanonicalizerPhase.java:210) > > at > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.run(CanonicalizerPhase.java:180) > > at > > com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:104) > > at > > com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:1) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) > > at com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:116) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) > > at com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) > > at > > com.oracle.graal.compiler.GraalCompiler.emitFrontEnd(GraalCompiler.java:200) > > > > > > On Wed, Jun 15, 2016 at 8:03 PM, Bahram Yarahmadi < > > bahram.yarahmadi at gmail.com > wrote: > > > >> Thanks for your help christian ,It worked > >> I want to modify the graph an insert my own InvokeNode with > >> MethodCallTargetNode to graph but according to the post from this mailing > >> list ( > >> http://mail.openjdk.java.net/pipermail/graal-dev/2013-July/000650.html" > >> it was impossible.Is it possible after about three years ?! > >> This is my code,I get an error when I try to run it with unittest > >> StructuredGraph graph = new StructuredGraph(AllowAssumptions.YES); > >> ReturnNode returnNode = graph.add(new ReturnNode(null)); > >> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), > >> StampFactory.intValue()); > >> ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), > >> StampFactory.intValue());where and there needs to be a state where the VM can deoptimize to. > >> ValueNode[] valueNodes = new ValueNode[2]; > >> valueNodes[0] = valueNode1; > >> valueNodes[1] = valueNode2; > >> graph.addWithoutUnique(valueNode1); > >> graph.addWithoutUnique(valueNode2); > >> ResolvedJavaMethod method = findMethod(Student.class, "SubInt"); > >> MethodCallTargetNode callTarget = graph.add(new > >> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, > >> method, valueNodes, StampFactory.forDeclaredType(null, > >> method.getSignature().getReturnType(null), false), null)); > >> InvokeNode ink = graph.add(new InvokeNode(callTarget, > >> BytecodeFrame.UNWIND_BCI)); > >> graph.start().setNext(ink); > >> ink.setNext(returnNode); > >> OptimisticOptimizations optimisticOpts = > >> OptimisticOptimizations.ALL; > >> PhaseSuite graphBuilderSuite = > >> backend.getSuites().getDefaultGraphBuilderSuite(); > >> Suites suites = backend.getSuites().getDefaultSuites(); > >> LIRSuites lirSuites = backend.getSuites().getDefaultLIRSuites(); > >> ProfilingInfo profilingInfo = graph.getProfilingInfo(method); > >> CompilationResult compilationResult = new CompilationResult(); > >> CompilationResultBuilderFactory factory = > >> CompilationResultBuilderFactory.Default; > >> GraalCompiler.compileGraph(graph, method, providers, backend, > >> graphBuilderSuite, > >> optimisticOpts, profilingInfo, suites, lirSuites, > >> compilationResult, factory); > >> CompiledCode compiledCode = backend.createCompiledCode(method, > >> compilationResult); > >> InstalledCode installedCode = codeCache.addCode(method, > >> compiledCode, null, null); > >> try { > >> installedCode.executeVarargs(); > >> > >> } catch (InvalidInstalledCodeException e) { > >> > >> e.printStackTrace(); > >> } > >> and by the way,Is it a correct way to compile a graph ? or It is better to > >> write my own compilation phases > >> > >> Thanks again > >> > >> Regards > >> > >> > >> > >> > >> On Tue, Jun 14, 2016 at 10:54 PM, Christian Wimmer < > >> christian.wimmer at oracle.com > wrote: > >> > >>> Seems like you are not adding the ConstantNode to the graph. > >>> > >>> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), > >>> StampFactory.intValue()); > >>> > >>> should be > >>> > >>> ValueNode valueNode1 = graph.unique(new > >>> ConstantNode(JavaConstant.forInt(154), StampFactory.intValue())); > >>> > >>> Since constants are floating nodes, you need to use unique() instead of > >>> add() - but they still need to be made part of the graph. > >>> > >>> -Christian > >>> > >>> > >>> > >>> On 06/14/2016 01:44 AM, Bahram Yarahmadi wrote: > >>> > >>>> Hello guys, > >>>> > >>>> I want to build a graph manually but when I want to add an invokeNode to > >>>> the graph I get an error > >>>> this is my code : > >>>> StructuredGraph graph = new > >>>> StructuredGraph(AllowAssumptions.YES); > >>>> ReturnNode returnNode = graph.add(new ReturnNode(null)); > >>>> ValueNode valueNode1 = new ConstantNode(JavaConstant.forInt(154), > >>>> StampFactory.intValue()); > >>>> ValueNode valueNode2 = new ConstantNode(JavaConstant.forInt(25), > >>>> StampFactory.intValue()); > >>>> ValueNode[] valueNodes = new ValueNode[2]; > >>>> valueNodes[0] = valueNode1; > >>>> valueNodes[1] = valueNode2; > >>>> ResolvedJavaMethod method = findMethod(AA.class, "SubInt"); > >>>> MethodCallTargetNode callTarget = graph.add(new > >>>> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, > >>>> method, valueNodes, > >>>> StampFactory.forDeclaredType(null, > >>>> method.getSignature().getReturnType(null), false), null)); > >>>> InvokeNode ink = graph.add(new InvokeNode(callTarget, > >>>> BytecodeFrame.UNWIND_BCI)); > >>>> graph.start().setNext(ink); > >>>> ink.setNext(returnNode); > >>>> Debug.dump(Debug.BASIC_LOG_LEVEL, graph, "Graph"); > >>>> and my SubInt method is > >>>> > >>>> public static void SubInt(int a, int b) { > >>>> System.out.println("///"); > >>>> } > >>>> but when I try to test with inittest I get this error : > >>>> testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > >>>> java.lang.AssertionError: Input not alive > >>>> at > >>>> > >>>> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsageHelper(NodeClass.java:1257) > >>>> at > >>>> > >>>> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsage(NodeClass.java:1245) > >>>> at com.oracle.graal.graph.Node.initialize(Node.java:593) > >>>> at com.oracle.graal.graph.Graph.addHelper(Graph.java:446) > >>>> at com.oracle.graal.graph.Graph.add(Graph.java:398) > >>>> at > >>>> > >>>> com.oracle.graal.compiler.test.tutorial.GraalTutorial.testPrintBytecodes(GraalTutorial.java:278) > >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >>>> at > >>>> > >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >>>> at > >>>> > >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >>>> at java.lang.reflect.Method.invoke(Method.java:498) > >>>> > >>>> > >>>> > >>>> Thanks again > >>>> > >>>> Bahram, > >>>> > >>>> > >> > > > From forax at univ-mlv.fr Mon Jun 20 10:15:24 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 20 Jun 2016 12:15:24 +0200 (CEST) Subject: Building a graph manually In-Reply-To: References: <57604BF5.6080102@oracle.com> <29658725-cace-0bcc-9a9b-1ef6e1d36676@oracle.com> Message-ID: <777045783.174991.1466417724015.JavaMail.zimbra@u-pem.fr> Or use ASM [1] which is used internally by DiSL. The OpenJDK also holds a partial copy of ASM in the internal package jdk.internal.org.objectweb.asm R?mi [1] http://asm.ow2.org/ ----- Mail original ----- > De: "Gilles Duboscq" > ?: "Bahram Yarahmadi" > Cc: graal-dev at openjdk.java.net > Envoy?: Lundi 20 Juin 2016 11:49:58 > Objet: Re: Building a graph manually > > Hi, > > Any bytecode instrumentation framework should work with Graal. > Maybe you could have a look at DiSL [1] for example. > > Gilles > > [1] https://disl.ow2.org/bin/view/Main/ > > On 18/06/16 10:14, Bahram Yarahmadi wrote: > > Hi guys > > Does anyone here know any proper bytecode instrumentation which I can use > > it with graal !? > > > > On Fri, Jun 17, 2016 at 1:11 PM, Bahram Yarahmadi > > > wrote: > > > > Thanks Gilles > > I cannot even build the state on the fly,I think it must be a non > > trivial task > > I made some progress and now for "just some" methods , I can redirect > > an invoke with InliningUtil.replaceInvokeCallTarget , > > for instance :I can invoke method X() instead of method Y() at runtime > > but my target is Lambdas with stream APIs , > > for example: > > Intstream.rang(0,10).parallel.foreach(....) > > I modify the graph and I delete invoke#range,invoke#parallel > > ,invoke#foreach from cfg > > I made a pure control flow which only contains > > 285377351.linkToTargetMethod as an invoke node which is static but > > when I want to redirect this method I get this Error > > testGraphKitTool(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > > java.lang.NullPointerException > > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > > at > > com.oracle.graal.compiler.test.tutorial.GraalTutorial.testGraphKitTool(GraalTutorial.java:449) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:498) > > at > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > > at > > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > > at > > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > > at > > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > > at > > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > > at > > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > > at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:167) > > > > Time: 0.249 > > There was 1 failure: > > 1) > > testGraphKitTool(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > > java.lang.NullPointerException > > at com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > > at > > com.oracle.graal.compiler.test.tutorial.GraalTutorial.testGraphKitTool(GraalTutorial.java:449) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:498) > > at > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > > at > > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > > at > > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > > at > > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > > at > > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > > at > > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > > at com.oracle.mxtool.junit.MxJUnitWrapper.main(MxJUnitWrapper.java:167) > > > > > > What is the difference between these two scenarios?? > > Can I Interpret my graph instead of compile in graal in this case ?? > > > > Thanks > > > > Bahram > > > > On Wed, Jun 15, 2016 at 8:21 PM, Gilles Duboscq > > > > > wrote: > > > > Hi, > > > > Your InvokeNode does not seem to have a valid FrameState node. > > > > The reason why it's hard to create an InvokeNode out of the blue is > > that in order to install code, it has to make sense for the VM. > > For example, there needs to be a corresponding invoke bytecode > > somewhere and there needs to be a state where the VM can > > deoptimize to. > > > > Gilles > > > > On 15/06/16 17:35, Bahram Yarahmadi wrote: > > > And this is the error that I always get > > > [thread:1] scope: > > > main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException > > > Exception occurred in scope: > > > main.GraalCompilerRoot.GraalCompiler.FrontEnd.HighTier.CanonicalizerPhase.InterceptException > > > Context obj java.lang.NullPointerException > > > Context obj > > > com.oracle.graal.phases.common.CanonicalizerPhase at 77556fd > > > Context obj > > > com.oracle.graal.compiler.phases.HighTier at 368239c8 > > > Context obj StructuredGraph:1 > > > Context obj > > > jdk.vm.ci.hotspot.HotSpotCodeCacheProvider at 3b192d32 > > > E > > > testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > > > java.lang.NullPointerException > > > at > > > com.oracle.graal.nodes.Invoke.getContextMethod(Invoke.java:75) > > > at > > > com.oracle.graal.nodes.java.MethodCallTargetNode.simplify(MethodCallTargetNode.java:165) > > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.tryCanonicalize(CanonicalizerPhase.java:308) > > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processNode(CanonicalizerPhase.java:225) > > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.processWorkSet(CanonicalizerPhase.java:210) > > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase$Instance.run(CanonicalizerPhase.java:180) > > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:104) > > > at > > > com.oracle.graal.phases.common.CanonicalizerPhase.run(CanonicalizerPhase.java:1) > > > at > > > com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) > > > at > > > com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) > > > at > > > com.oracle.graal.phases.PhaseSuite.run(PhaseSuite.java:116) > > > at > > > com.oracle.graal.phases.BasePhase.apply(BasePhase.java:143) > > > at > > > com.oracle.graal.phases.BasePhase.apply(BasePhase.java:133) > > > at > > > com.oracle.graal.compiler.GraalCompiler.emitFrontEnd(GraalCompiler.java:200) > > > > > > > > > On Wed, Jun 15, 2016 at 8:03 PM, Bahram Yarahmadi < > > > bahram.yarahmadi at gmail.com > > > > wrote: > > > > > >> Thanks for your help christian ,It worked > > >> I want to modify the graph an insert my own InvokeNode with > > >> MethodCallTargetNode to graph but according to the post from > > >> this mailing > > >> list ( > > >> http://mail.openjdk.java.net/pipermail/graal-dev/2013-July/000650.html" > > >> it was impossible.Is it possible after about three years ?! > > >> This is my code,I get an error when I try to run it with > > >> unittest > > >> StructuredGraph graph = new > > >> StructuredGraph(AllowAssumptions.YES); > > >> ReturnNode returnNode = graph.add(new ReturnNode(null)); > > >> ValueNode valueNode1 = new > > >> ConstantNode(JavaConstant.forInt(154), > > >> StampFactory.intValue()); > > >> ValueNode valueNode2 = new > > >> ConstantNode(JavaConstant.forInt(25), > > >> StampFactory.intValue());where and there needs to be a state > > >> where the VM can deoptimize to. > > >> ValueNode[] valueNodes = new ValueNode[2]; > > >> valueNodes[0] = valueNode1; > > >> valueNodes[1] = valueNode2; > > >> graph.addWithoutUnique(valueNode1); > > >> graph.addWithoutUnique(valueNode2); > > >> ResolvedJavaMethod method = findMethod(Student.class, > > >> "SubInt"); > > >> MethodCallTargetNode callTarget = graph.add(new > > >> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, > > >> method, valueNodes, StampFactory.forDeclaredType(null, > > >> method.getSignature().getReturnType(null), false), null)); > > >> InvokeNode ink = graph.add(new InvokeNode(callTarget, > > >> BytecodeFrame.UNWIND_BCI)); > > >> graph.start().setNext(ink); > > >> ink.setNext(returnNode); > > >> OptimisticOptimizations optimisticOpts = > > >> OptimisticOptimizations.ALL; > > >> PhaseSuite graphBuilderSuite = > > >> backend.getSuites().getDefaultGraphBuilderSuite(); > > >> Suites suites = backend.getSuites().getDefaultSuites(); > > >> LIRSuites lirSuites = > > >> backend.getSuites().getDefaultLIRSuites(); > > >> ProfilingInfo profilingInfo = > > >> graph.getProfilingInfo(method); > > >> CompilationResult compilationResult = new > > >> CompilationResult(); > > >> CompilationResultBuilderFactory factory = > > >> CompilationResultBuilderFactory.Default; > > >> GraalCompiler.compileGraph(graph, method, providers, > > >> backend, > > >> graphBuilderSuite, > > >> optimisticOpts, profilingInfo, suites, lirSuites, > > >> compilationResult, factory); > > >> CompiledCode compiledCode = > > >> backend.createCompiledCode(method, > > >> compilationResult); > > >> InstalledCode installedCode = codeCache.addCode(method, > > >> compiledCode, null, null); > > >> try { > > >> installedCode.executeVarargs(); > > >> > > >> } catch (InvalidInstalledCodeException e) { > > >> > > >> e.printStackTrace(); > > >> } > > >> and by the way,Is it a correct way to compile a graph ? or It is > > >> better to > > >> write my own compilation phases > > >> > > >> Thanks again > > >> > > >> Regards > > >> > > >> > > >> > > >> > > >> On Tue, Jun 14, 2016 at 10:54 PM, Christian Wimmer < > > >> christian.wimmer at oracle.com > > >> > wrote: > > >> > > >>> Seems like you are not adding the ConstantNode to the graph. > > >>> > > >>> ValueNode valueNode1 = new > > >>> ConstantNode(JavaConstant.forInt(154), > > >>> StampFactory.intValue()); > > >>> > > >>> should be > > >>> > > >>> ValueNode valueNode1 = graph.unique(new > > >>> ConstantNode(JavaConstant.forInt(154), > > >>> StampFactory.intValue())); > > >>> > > >>> Since constants are floating nodes, you need to use unique() > > >>> instead of > > >>> add() - but they still need to be made part of the graph. > > >>> > > >>> -Christian > > >>> > > >>> > > >>> > > >>> On 06/14/2016 01:44 AM, Bahram Yarahmadi wrote: > > >>> > > >>>> Hello guys, > > >>>> > > >>>> I want to build a graph manually but when I want to add an > > >>>> invokeNode to > > >>>> the graph I get an error > > >>>> this is my code : > > >>>> StructuredGraph graph = new > > >>>> StructuredGraph(AllowAssumptions.YES); > > >>>> ReturnNode returnNode = graph.add(new > > >>>> ReturnNode(null)); > > >>>> ValueNode valueNode1 = new > > >>>> ConstantNode(JavaConstant.forInt(154), > > >>>> StampFactory.intValue()); > > >>>> ValueNode valueNode2 = new > > >>>> ConstantNode(JavaConstant.forInt(25), > > >>>> StampFactory.intValue()); > > >>>> ValueNode[] valueNodes = new ValueNode[2]; > > >>>> valueNodes[0] = valueNode1; > > >>>> valueNodes[1] = valueNode2; > > >>>> ResolvedJavaMethod method = findMethod(AA.class, "SubInt"); > > >>>> MethodCallTargetNode callTarget = graph.add(new > > >>>> MethodCallTargetNode(MethodCallTargetNode.InvokeKind.Static, > > >>>> method, valueNodes, > > >>>> StampFactory.forDeclaredType(null, > > >>>> method.getSignature().getReturnType(null), false), null)); > > >>>> InvokeNode ink = graph.add(new InvokeNode(callTarget, > > >>>> BytecodeFrame.UNWIND_BCI)); > > >>>> graph.start().setNext(ink); > > >>>> ink.setNext(returnNode); > > >>>> Debug.dump(Debug.BASIC_LOG_LEVEL, graph, "Graph"); > > >>>> and my SubInt method is > > >>>> > > >>>> public static void SubInt(int a, int b) { > > >>>> System.out.println("///"); > > >>>> } > > >>>> but when I try to test with inittest I get this error : > > >>>> testPrintBytecodes(com.oracle.graal.compiler.test.tutorial.GraalTutorial) > > >>>> java.lang.AssertionError: Input not alive > > >>>> at > > >>>> > > >>>> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsageHelper(NodeClass.java:1257) > > >>>> at > > >>>> > > >>>> com.oracle.graal.graph.NodeClass.registerAtInputsAsUsage(NodeClass.java:1245) > > >>>> at com.oracle.graal.graph.Node.initialize(Node.java:593) > > >>>> at com.oracle.graal.graph.Graph.addHelper(Graph.java:446) > > >>>> at com.oracle.graal.graph.Graph.add(Graph.java:398) > > >>>> at > > >>>> > > >>>> com.oracle.graal.compiler.test.tutorial.GraalTutorial.testPrintBytecodes(GraalTutorial.java:278) > > >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > >>>> Method) > > >>>> at > > >>>> > > >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > >>>> at > > >>>> > > >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > >>>> at java.lang.reflect.Method.invoke(Method.java:498) > > >>>> > > >>>> > > >>>> > > >>>> Thanks again > > >>>> > > >>>> Bahram, > > >>>> > > >>>> > > >> > > > > > > > From christian.wimmer at oracle.com Mon Jun 20 17:55:52 2016 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Mon, 20 Jun 2016 10:55:52 -0700 Subject: Recording of Truffle Tutorial Message-ID: <57682E28.2000702@oracle.com> Hi Truffle users, A new version of the 3-hour tutorial on Truffle is available on YouTube [1], and the slides are available for download [2]. Everything is also linked from the usual publications page [3]. The tutorial covers the basics of Truffle, but also showcases our language integration and tool support for Truffle languages. -Christian [1] https://youtu.be/FJY96_6Y3a4 [2] https://lafo.ssw.uni-linz.ac.at/pub/papers/2016_PLDI_Truffle.pdf [3] https://wiki.openjdk.java.net/display/Graal/Publications+and+Presentations From doug.simon at oracle.com Mon Jun 20 18:21:24 2016 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 20 Jun 2016 20:21:24 +0200 Subject: jvmci-0.15 release Message-ID: <872D8BA0-305F-418E-9163-00E0E1A1543F@oracle.com> Due to a number of issues identified by FindBugs[1] when run over the JVMCI code in JDK9, a number of JVMCI changes had to be made, including API changes. These changes have already been pushed to graal-jvmci-8[2] along with a new tag (i.e., jvmci-0.15). The graal-core changes that adopt the JVMCI API changes are also pushed[3][4]. -Doug [1] http://findbugs.sourceforge.net [2] http://hg.openjdk.java.net/graal/graal-jvmci-8/rev/abebb99b6b50 [3] https://github.com/graalvm/graal-core/commit/9489b088c704c3f323f973a98338cf3300492271 [4] http://hg.openjdk.java.net/graal/graal-core/rev/190661a57365 From jaroslav.tulach at oracle.com Tue Jun 21 12:53:45 2016 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 21 Jun 2016 14:53:45 +0200 Subject: Executing unknown code? Stop it after 10s! Message-ID: <4366531.YHqLMFSLEH@pracovni> Hi. There was a request for an enhancement of the Truffle API to shield one from executing foreign unknown code endlessly. It turned out that such functionality is already possible thanks to instrumentation framework and its usage in debugger API. I've just made the sample part of our Javadoc: http://lafo.ssw.uni-linz.ac.at/javadoc/truffle/latest/com/oracle/truffle/api/debug/SuspendedEvent.html#prepareKill-- The code is now also part of the Truffle TCK - e.g. every Truffle-compliant language is guaranteed to support this kind of "timed out" execution: > Added Methods > ------------- > > com.oracle.truffle.tck.TruffleTCK: method protected String countUpWhile() > com.oracle.truffle.tck.TruffleTCK: method public void timeOutTest() Enjoy interrupting your executions! -jt From john.bergin at gmail.com Fri Jun 24 14:11:42 2016 From: john.bergin at gmail.com (john bergin) Date: Fri, 24 Jun 2016 15:11:42 +0100 Subject: Production ready? Graal essential for JITing? Message-ID: Hi. I understand that Truffle and Graal are research projects and that there is currently no set date for a release. But I'm wondering if there is a Truffle commit that is considered safe for production on a standard JVM? I'm also wondering if Graal is needed to allow a Truffle AST to be optimized for a specific run-time context? My understand is Truffle is a AST framework and Graal is the JIT and Graal feeds optimizations back to the Truffle AST to suggest specific optimizations? Or maybe Truffle on its own running on a stock JVM can allow for JITing of the Truffle AST. Appreciate any feedback on either question. Many thanks. John. From raffaello.giulietti at supsi.ch Fri Jun 24 14:57:32 2016 From: raffaello.giulietti at supsi.ch (Raffaello Giulietti) Date: Fri, 24 Jun 2016 14:57:32 +0000 Subject: Production ready? Graal essential for JITing? In-Reply-To: References: Message-ID: <44610c2f-7abd-1d8e-16e0-ed1a1dd8f23b@supsi.ch> Hi, this is my understanding: * Truffle optimizes when it can interact with a JVMCI [http://openjdk.java.net/jeps/243] enabled VM. * Graal implements the JVMCI. * Hence, Truffle + Graal is the winning pair. Truffle still runs on a stock JVM but it then simply acts as a self-optimizing *interpreter*. The real magic happens when it can interplay with a JVMCI jitting compiler like Graal. That said, I'm not sure how far Truffle is committed to Graal's internals and how far it only depends on the pure interface aspect of JVMCI. It is planned that JVMCI will be an experimental feature in Java 9, so the next EA releases of Java 9 will probably support the whole suite without the need to build the JVM from source. To answer your question, yes, Graal is currently essential for jitting. Greetings Raffaello On 2016-06-24 14:11, john bergin wrote: > Hi. > > I understand that Truffle and Graal are research projects and that there is > currently no set date for a release. But I'm wondering if there is a > Truffle commit that is considered safe for production on a standard JVM? > > I'm also wondering if Graal is needed to allow a Truffle AST to be > optimized for a specific run-time context? My understand is Truffle is a > AST framework and Graal is the JIT and Graal feeds optimizations back to > the Truffle AST to suggest specific optimizations? Or maybe Truffle on its > own running on a stock JVM can allow for JITing of the Truffle AST. > > Appreciate any feedback on either question. > > Many thanks. > John. > From christian.humer at gmail.com Fri Jun 24 15:06:59 2016 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 24 Jun 2016 15:06:59 +0000 Subject: Production ready? Graal essential for JITing? In-Reply-To: References: Message-ID: Hi John, Thanks for your interest. I cannot answer a "safe for production" question, as Truffle is still a research project. We tag our Truffle Github repository[1] with releases of the API. The latest Truffle release tag is truffle-0.14. We do guarantee compatibility between two adjacent versions, however we may mark API as deprecated in one release and remove them in a later one at the moment. So for upgrading you can go to the next Truffle version, fix all deprecated warnings and repeat with the next version until you reach the desired version. Every Truffle release should run with a standard JVM >= 1.7 out of the box. However you won't get the benefit of Graal optimizing the ASTs using dynamic compilation in such a scenario. We are currently integrating our VM facing APIs called JVMCI[2] into JDK9. So with a stock JDK9 you are going to be able run Truffle together with Graal as a JIT. In the meantime, you can already use a modified JDK8 version called GraalVM[3] for development. This version of the JDK includes JVMCI, Graal, Truffle and also ships with interpreters for JavaScript, Ruby and R. To get started with Truffle language development I recommend to have a look at SimpleLanguage[4] and a recently published Truffle video tutorial[5] by Christian Wimmer. Hope this helps. Have fun, Christian Humer [1] https://github.com/graalvm/truffle [2] http://openjdk.java.net/jeps/243 [3] http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html [4] https://github.com/graalvm/simplelanguage [5] https://www.youtube.com/watch?v=FJY96_6Y3a4 On 24.06.2016 16:11:42, "john bergin" wrote: >Hi. > >I understand that Truffle and Graal are research projects and that >there is >currently no set date for a release. But I'm wondering if there is a >Truffle commit that is considered safe for production on a standard >JVM? > >I'm also wondering if Graal is needed to allow a Truffle AST to be >optimized for a specific run-time context? My understand is Truffle is >a >AST framework and Graal is the JIT and Graal feeds optimizations back >to >the Truffle AST to suggest specific optimizations? Or maybe Truffle on >its >own running on a stock JVM can allow for JITing of the Truffle AST. > >Appreciate any feedback on either question. > >Many thanks. >John. From john.bergin at gmail.com Fri Jun 24 15:21:42 2016 From: john.bergin at gmail.com (john bergin) Date: Fri, 24 Jun 2016 16:21:42 +0100 Subject: Production ready? Graal essential for JITing? In-Reply-To: References: Message-ID: Thank you Raffaello / Christian for your prompt responses!! Now knowing that JVMCI is the link between Truffle and Graal makes the picture a lot more clear! OK so Truffle running on a stock JVM acts as a self-optimizing interpreter. I believe the paper linked below describes the work done by Tuffle. Am I correct on this? http://lafo.ssw.uni-linz.ac.at/papers/2012_DLS_SelfOptimizingASTInterpreters.pdf Interesting to know that JVMCI will be a experimental feature in JDK9. Thanks for all the links, Christian, and SimpleLanguage looks especially interesting. I'll give the video a watch too. Thanks for the info. Lots to get started with. On 24 June 2016 at 16:06, Christian Humer wrote: > Hi John, > > Thanks for your interest. > > I cannot answer a "safe for production" question, as Truffle is still a > research project. > We tag our Truffle Github repository[1] with releases of the API. The > latest Truffle release tag is truffle-0.14. > We do guarantee compatibility between two adjacent versions, however we > may mark API as deprecated in one release and remove them in a later one at > the moment. > So for upgrading you can go to the next Truffle version, fix all > deprecated warnings and repeat with the next version until you reach the > desired version. > > Every Truffle release should run with a standard JVM >= 1.7 out of the box. > However you won't get the benefit of Graal optimizing the ASTs using > dynamic compilation in such a scenario. > We are currently integrating our VM facing APIs called JVMCI[2] into JDK9. > So with a stock JDK9 you are going to be able run Truffle together with > Graal as a JIT. > > In the meantime, you can already use a modified JDK8 version called > GraalVM[3] for development. > This version of the JDK includes JVMCI, Graal, Truffle and also ships with > interpreters for JavaScript, Ruby and R. > To get started with Truffle language development I recommend to have a > look at SimpleLanguage[4] and a recently published Truffle video > tutorial[5] by Christian Wimmer. > > Hope this helps. > > Have fun, > Christian Humer > > > [1] https://github.com/graalvm/truffle > [2] http://openjdk.java.net/jeps/243 > [3] > http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html > [4] https://github.com/graalvm/simplelanguage > [5] https://www.youtube.com/watch?v=FJY96_6Y3a4 > > > > On 24.06.2016 16:11:42, "john bergin" wrote: > > Hi. >> >> I understand that Truffle and Graal are research projects and that there >> is >> currently no set date for a release. But I'm wondering if there is a >> Truffle commit that is considered safe for production on a standard JVM? >> >> I'm also wondering if Graal is needed to allow a Truffle AST to be >> optimized for a specific run-time context? My understand is Truffle is a >> AST framework and Graal is the JIT and Graal feeds optimizations back to >> the Truffle AST to suggest specific optimizations? Or maybe Truffle on its >> own running on a stock JVM can allow for JITing of the Truffle AST. >> >> Appreciate any feedback on either question. >> >> Many thanks. >> John. >> > > From christian.humer at gmail.com Fri Jun 24 15:59:55 2016 From: christian.humer at gmail.com (Christian Humer) Date: Fri, 24 Jun 2016 15:59:55 +0000 Subject: Production ready? Graal essential for JITing? In-Reply-To: References: Message-ID: Great. Please let me know if you need further help getting started. We also appreciate feedback on the process. Good luck! Cheers, Christian On 24.06.2016 17:21:42, "john bergin" wrote: >Thank you Raffaello / Christian for your prompt responses!! > >Now knowing that JVMCI is the link between Truffle and Graal makes the >picture a lot more clear! > >OK so Truffle running on a stock JVM acts as a self-optimizing >interpreter. >I believe the paper linked below describes the work done by Tuffle. Am >I >correct on this? > >http://lafo.ssw.uni-linz.ac.at/papers/2012_DLS_SelfOptimizingASTInterpreters.pdf > >Interesting to know that JVMCI will be a experimental feature in JDK9. > >Thanks for all the links, Christian, and SimpleLanguage looks >especially >interesting. I'll give the video a watch too. > >Thanks for the info. Lots to get started with. > >On 24 June 2016 at 16:06, Christian Humer >wrote: > >> Hi John, >> >> Thanks for your interest. >> >> I cannot answer a "safe for production" question, as Truffle is still >>a >> research project. >> We tag our Truffle Github repository[1] with releases of the API. The >> latest Truffle release tag is truffle-0.14. >> We do guarantee compatibility between two adjacent versions, however >>we >> may mark API as deprecated in one release and remove them in a later >>one at >> the moment. >> So for upgrading you can go to the next Truffle version, fix all >> deprecated warnings and repeat with the next version until you reach >>the >> desired version. >> >> Every Truffle release should run with a standard JVM >= 1.7 out of >>the box. >> However you won't get the benefit of Graal optimizing the ASTs using >> dynamic compilation in such a scenario. >> We are currently integrating our VM facing APIs called JVMCI[2] into >>JDK9. >> So with a stock JDK9 you are going to be able run Truffle together >>with >> Graal as a JIT. >> >> In the meantime, you can already use a modified JDK8 version called >> GraalVM[3] for development. >> This version of the JDK includes JVMCI, Graal, Truffle and also ships >>with >> interpreters for JavaScript, Ruby and R. >> To get started with Truffle language development I recommend to have >>a >> look at SimpleLanguage[4] and a recently published Truffle video >> tutorial[5] by Christian Wimmer. >> >> Hope this helps. >> >> Have fun, >> Christian Humer >> >> >> [1] https://github.com/graalvm/truffle >> [2] http://openjdk.java.net/jeps/243 >> [3] >> >>http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html >> [4] https://github.com/graalvm/simplelanguage >> [5] https://www.youtube.com/watch?v=FJY96_6Y3a4 >> >> >> >> On 24.06.2016 16:11:42, "john bergin" wrote: >> >> Hi. >>> >>> I understand that Truffle and Graal are research projects and that >>>there >>> is >>> currently no set date for a release. But I'm wondering if there is a >>> Truffle commit that is considered safe for production on a standard >>>JVM? >>> >>> I'm also wondering if Graal is needed to allow a Truffle AST to be >>> optimized for a specific run-time context? My understand is Truffle >>>is a >>> AST framework and Graal is the JIT and Graal feeds optimizations >>>back to >>> the Truffle AST to suggest specific optimizations? Or maybe Truffle >>>on its >>> own running on a stock JVM can allow for JITing of the Truffle AST. >>> >>> Appreciate any feedback on either question. >>> >>> Many thanks. >>> John. >>> >> >> From christian.humer at gmail.com Sun Jun 26 15:23:22 2016 From: christian.humer at gmail.com (Christian Humer) Date: Sun, 26 Jun 2016 15:23:22 +0000 Subject: Truffle DSL broken for Eclipse Neon Message-ID: Hi folks, Just a short notice that Truffle 0.14 is broken for use in Eclipse Neon. Eclipse versions prior Neon and other IDEs are not affected by this bug. In order to use Truffle with Eclipse Neon you need to use the latest Truffle revision from Github[1]. The bugfix will be included in the next Truffle 0.15 release. Cheers, Christian Humer [1] https://github.com/graalvm/truffle/commit/26cc3e2de42f92c78b6eb0876dd6759eb9c7001a From raffaello.giulietti at supsi.ch Tue Jun 28 20:46:34 2016 From: raffaello.giulietti at supsi.ch (Raffaello Giulietti) Date: Tue, 28 Jun 2016 20:46:34 +0000 Subject: Object inlining, aka object fusing Message-ID: <3e874f49-342b-244e-fbd0-bb4b4dc33bde@supsi.ch> Hi all, this is perhaps not the right place for questions related to object memory layout in HotSpot, but I dare to ask anyway given the tremendous expertise about this JVM internals by the Graal developers reading this list. Some years ago, Christian Wimmer and Hanspeter M?ssenb?ck conducted research on object inlining (http://www.ssw.uni-linz.ac.at/Research/Projects/JVM/AOI.html) and experimented the idea in HotSpot. Anybody knows whether their code managed to be officially integrated in the stock HotSpot VM, and thus also in the JVMCI extended version used by Truffle/Graal? Thanks Raffaello From rednaxelafx at gmail.com Tue Jun 28 20:49:13 2016 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 28 Jun 2016 13:49:13 -0700 Subject: Object inlining, aka object fusing In-Reply-To: <3e874f49-342b-244e-fbd0-bb4b4dc33bde@supsi.ch> References: <3e874f49-342b-244e-fbd0-bb4b4dc33bde@supsi.ch> Message-ID: Hi Raffaello, It's safe to say the the object inlining code has not made it upstream to the production OpenJDK HotSpot VM. - Kris (OpenJDK username: kmo) On Tue, Jun 28, 2016 at 1:46 PM, Raffaello Giulietti < raffaello.giulietti at supsi.ch> wrote: > Hi all, > > this is perhaps not the right place for questions related to object > memory layout in HotSpot, but I dare to ask anyway given the tremendous > expertise about this JVM internals by the Graal developers reading this > list. > > Some years ago, Christian Wimmer and Hanspeter M?ssenb?ck conducted > research on object inlining > (http://www.ssw.uni-linz.ac.at/Research/Projects/JVM/AOI.html) and > experimented the idea in HotSpot. > > Anybody knows whether their code managed to be officially integrated in > the stock HotSpot VM, and thus also in the JVMCI extended version used > by Truffle/Graal? > > Thanks > Raffaello > > From christian.wimmer at oracle.com Tue Jun 28 23:32:09 2016 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Tue, 28 Jun 2016 16:32:09 -0700 Subject: Object inlining, aka object fusing In-Reply-To: <3e874f49-342b-244e-fbd0-bb4b4dc33bde@supsi.ch> References: <3e874f49-342b-244e-fbd0-bb4b4dc33bde@supsi.ch> Message-ID: <577308F9.2080401@oracle.com> Hi, The object inlining was a research prototype (like many other PhD theses). It was never intended to be production-ready, so it is not in the product version. It was also way before Graal got started (object inlining is implemented in the client compiler only). Graal would certainly have saved me some time back in the days... -Christian On 06/28/2016 01:46 PM, Raffaello Giulietti wrote: > Hi all, > > this is perhaps not the right place for questions related to object > memory layout in HotSpot, but I dare to ask anyway given the tremendous > expertise about this JVM internals by the Graal developers reading this > list. > > Some years ago, Christian Wimmer and Hanspeter M?ssenb?ck conducted > research on object inlining > (http://www.ssw.uni-linz.ac.at/Research/Projects/JVM/AOI.html) and > experimented the idea in HotSpot. > > Anybody knows whether their code managed to be officially integrated in > the stock HotSpot VM, and thus also in the JVMCI extended version used > by Truffle/Graal? > > Thanks > Raffaello > From tom.rodriguez at oracle.com Wed Jun 29 00:17:05 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 28 Jun 2016 17:17:05 -0700 Subject: Object inlining, aka object fusing In-Reply-To: <577308F9.2080401@oracle.com> References: <3e874f49-342b-244e-fbd0-bb4b4dc33bde@supsi.ch> <577308F9.2080401@oracle.com> Message-ID: <1CFFF673-85DC-410F-8C43-3272A019401C@oracle.com> The ObjectLayout stuff from Azul presupposes control over the grouping of objects in a way that?s seems compatible with object inlining. Maybe if that?s ever supported in hotspot it could be leveraged for this. It would probably depend on how flexible the implementation in the GC is. tom > On Jun 28, 2016, at 4:32 PM, Christian Wimmer wrote: > > Hi, > > The object inlining was a research prototype (like many other PhD theses). It was never intended to be production-ready, so it is not in the product version. It was also way before Graal got started (object inlining is implemented in the client compiler only). Graal would certainly have saved me some time back in the days... > > -Christian > > > On 06/28/2016 01:46 PM, Raffaello Giulietti wrote: >> Hi all, >> >> this is perhaps not the right place for questions related to object >> memory layout in HotSpot, but I dare to ask anyway given the tremendous >> expertise about this JVM internals by the Graal developers reading this >> list. >> >> Some years ago, Christian Wimmer and Hanspeter M?ssenb?ck conducted >> research on object inlining >> (http://www.ssw.uni-linz.ac.at/Research/Projects/JVM/AOI.html) and >> experimented the idea in HotSpot. >> >> Anybody knows whether their code managed to be officially integrated in >> the stock HotSpot VM, and thus also in the JVMCI extended version used >> by Truffle/Graal? >> >> Thanks >> Raffaello >> From doug.simon at oracle.com Wed Jun 29 08:20:59 2016 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 29 Jun 2016 10:20:59 +0200 Subject: Determining if JVMCI is enabled and whether it is being used by the JVM References: <8258cbee-a146-19f3-b7eb-374dc45ba102@oracle.com> Message-ID: Here?s some useful information on how to be able to query this kind of information from Java. > Begin forwarded message: > > From: Roland Schatz > Subject: Re: Problems building Graal-0.12 on Debian 8 > Date: 28 June 2016 at 13:23:19 GMT+2 > > It depends on what exactly you want to know: > > - Am I running a JDK that supports JVMCI? > Look at the "java.vm.version" system property. > On JDK 8, it will contain "jvmci-" for jvmci-enabled builds. > JDK 9 always has JVMCI built in. > > - Is JVMCI enabled and/or used? > For that, you can query the VM options (EnableJVMCI and UseJVMCICompiler) using the management API. > > - What compiler is selected? > That's in the "jvmci.Compiler" system property. > >> import java.lang.management.ManagementFactory; >> import com.sun.management.HotSpotDiagnosticMXBean; >> import com.sun.management.VMOption; >> >> class JVMCIQuery { >> public static void main(String[] args) { >> // Am I running on a JDK that supports JVMCI? >> String vm_version = System.getProperty("java.vm.version"); >> System.out.printf("java.vm.version = %s%n", vm_version); >> >> HotSpotDiagnosticMXBean bean = ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class); >> >> // Is JVMCI enabled? >> VMOption enableJVMCI = bean.getVMOption("EnableJVMCI"); >> System.out.println(enableJVMCI); >> >> // Is the system using the JVMCI compiler for normal compilations? >> VMOption useJVMCICompiler = bean.getVMOption("UseJVMCICompiler"); >> System.out.println(useJVMCICompiler); >> >> // What compiler is selected? >> String compiler = System.getProperty("jvmci.Compiler"); >> System.out.printf("jvmci.Compiler = %s%n", compiler); >> } >> } > > On a normal JDK 8 (without JVMCI), you'll get: > > [roland at oracle-rs graal-core]$ java -cp graal_fun JVMCIQuery > java.vm.version = 25.92-b14 > Exception in thread "main" java.lang.IllegalArgumentException: VM option "EnableJVMCI" does not exist > at sun.management.HotSpotDiagnostic.getVMOption(HotSpotDiagnostic.java:73) > at JVMCIQuery.main(JVMCIQuery.java:12) > > > On a JDK 8 with JVMCI (i.e. JVMCI enabled, but not used by default): > > [roland at oracle-rs graal-core]$ mx vm -cp graal_fun JVMCIQuery > java.vm.version = 25.71-b01-internal-jvmci-0.17-dev > VM option: EnableJVMCI value: true origin: VM_CREATION (read-only) > VM option: UseJVMCICompiler value: false origin: DEFAULT (read-only) > jvmci.Compiler = graal > > > On a JDK 8 with JVMCI, using Graal as the system compiler: > > [roland at oracle-rs graal-core]$ mx vm -cp graal_fun -XX:+UseJVMCICompiler JVMCIQuery > java.vm.version = 25.71-b01-internal-jvmci-0.17-dev > VM option: EnableJVMCI value: true origin: VM_CREATION (read-only) > VM option: UseJVMCICompiler value: true origin: VM_CREATION (read-only) > jvmci.Compiler = graal > > > - Roland From raffaello.giulietti at supsi.ch Wed Jun 29 13:36:53 2016 From: raffaello.giulietti at supsi.ch (Raffaello Giulietti) Date: Wed, 29 Jun 2016 13:36:53 +0000 Subject: Object inlining, aka object fusing In-Reply-To: <1CFFF673-85DC-410F-8C43-3272A019401C@oracle.com> References: <3e874f49-342b-244e-fbd0-bb4b4dc33bde@supsi.ch> <577308F9.2080401@oracle.com> <1CFFF673-85DC-410F-8C43-3272A019401C@oracle.com> Message-ID: <4aeb8ae9-5669-c7cf-9a93-57da2270b2bb@supsi.ch> Well, it seems to me that ObjectLayout has a stricter semantics than object inlining as advocated in Christian Wimmer's work. The latter is far more flexible and transparent. Of course, that also means that ObjectLayout probably requires less implementational efforts than object inlining. It's a pity that object layout could not make it into the official OpenJDK HotSpot. On 2016-06-29 00:17, Tom Rodriguez wrote: > The ObjectLayout stuff from Azul presupposes control over the grouping of objects in a way that?s seems compatible with object inlining. Maybe if that?s ever supported in hotspot it could be leveraged for this. It would probably depend on how flexible the implementation in the GC is. > > tom > >> On Jun 28, 2016, at 4:32 PM, Christian Wimmer wrote: >> >> Hi, >> >> The object inlining was a research prototype (like many other PhD theses). It was never intended to be production-ready, so it is not in the product version. It was also way before Graal got started (object inlining is implemented in the client compiler only). Graal would certainly have saved me some time back in the days... >> >> -Christian >> >> >> On 06/28/2016 01:46 PM, Raffaello Giulietti wrote: >>> Hi all, >>> >>> this is perhaps not the right place for questions related to object >>> memory layout in HotSpot, but I dare to ask anyway given the tremendous >>> expertise about this JVM internals by the Graal developers reading this >>> list. >>> >>> Some years ago, Christian Wimmer and Hanspeter M?ssenb?ck conducted >>> research on object inlining >>> (http://www.ssw.uni-linz.ac.at/Research/Projects/JVM/AOI.html) and >>> experimented the idea in HotSpot. >>> >>> Anybody knows whether their code managed to be officially integrated in >>> the stock HotSpot VM, and thus also in the JVMCI extended version used >>> by Truffle/Graal? >>> >>> Thanks >>> Raffaello >>> > From jaroslav.tulach at oracle.com Wed Jun 29 15:00:44 2016 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 29 Jun 2016 17:00:44 +0200 Subject: Preparing for release of Truffle 0.15 Message-ID: <1713949.OZpQiNAPPN@pracovni> Hi. There were people that wanted to know what were the recent changes in Truffle API. Here is a changelog that describes what have been done so far and shall be included in the upcoming version 0.15: https://github.com/jtulach/truffle/blob/ChangeLog/CHANGELOG.md -jt From christian.humer at gmail.com Wed Jun 29 16:58:02 2016 From: christian.humer at gmail.com (Christian Humer) Date: Wed, 29 Jun 2016 16:58:02 +0000 Subject: Truffle compatibility with graal-core Message-ID: Hi folks, Please take note that the latest graal-core revision requires at least Truffle revision 0e6abb415d814432c24e2fcd8d074c9d795b5e1c to compile. This means that graal-core cannot be used with an older Truffle revision anymore. Cheers, Christian Humer From jaroslav.tulach at oracle.com Thu Jun 30 06:38:48 2016 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 30 Jun 2016 08:38:48 +0200 Subject: Late API changes was: Preparing for release of Truffle 0.15 In-Reply-To: <1713949.OZpQiNAPPN@pracovni> References: <1713949.OZpQiNAPPN@pracovni> Message-ID: <9478096.oBmQR6jOkc@pracovni> ### Wednesday 29 of June 2016, 17:00:44 @ Jaroslav Tulach ### > Hi. > There were people that wanted to know what were the recent changes in > Truffle API. Here is a changelog that describes what have been done so far > and shall be included in the upcoming version 0.15: > > https://github.com/jtulach/truffle/blob/ChangeLog/CHANGELOG.md The change is in, together with late API changes done before Truffle 0.15 is out. -jt Missing Classes --------------- com.oracle.truffle.api.instrumentation.LoadSourceEventListener com.oracle.truffle.api.instrumentation.LoadSourceSectionEventListener Missing Methods --------------- com.oracle.truffle.api.instrumentation.Instrumenter: method public abstract com.oracle.truffle.api.instrumentation.EventBinding com.oracle.truffle.api.instrumentation.Instrumenter.attachLoadSourceListener(com.oracle.truffle.api.instrumentation.SourceSectionFilter,com.oracle.truffle.api.instrumentation.LoadSourceEventListener,boolean) com.oracle.truffle.api.instrumentation.Instrumenter: method public abstract com.oracle.truffle.api.instrumentation.EventBinding com.oracle.truffle.api.instrumentation.Instrumenter.attachLoadSourceSectionListener(com.oracle.truffle.api.instrumentation.SourceSectionFilter,com.oracle.truffle.api.instrumentation.LoadSourceSectionEventListener,boolean) Added Classes ------------- com.oracle.truffle.api.instrumentation.LoadSourceListener com.oracle.truffle.api.instrumentation.LoadSourceSectionListener Added Methods ------------- com.oracle.truffle.api.instrumentation.Instrumenter: method public abstract com.oracle.truffle.api.instrumentation.EventBinding com.oracle.truffle.api.instrumentation.Instrumenter.attachLoadSourceListener(com.oracle.truffle.api.instrumentation.SourceSectionFilter,com.oracle.truffle.api.instrumentation.LoadSourceListener,boolean) com.oracle.truffle.api.instrumentation.Instrumenter: method public abstract com.oracle.truffle.api.instrumentation.EventBinding com.oracle.truffle.api.instrumentation.Instrumenter.attachLoadSourceSectionListener(com.oracle.truffle.api.instrumentation.SourceSectionFilter,com.oracle.truffle.api.instrumentation.LoadSourceSectionListener,boolean)