From doug.simon at oracle.com Mon Apr 2 03:10:54 2012 From: doug.simon at oracle.com (Douglas Simon) Date: Mon, 2 Apr 2012 12:10:54 +0200 Subject: Graal - first step In-Reply-To: <4F75E9B1.20106@univ-mlv.fr> References: <4F75E9B1.20106@univ-mlv.fr> Message-ID: <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> Hi Remi, On Mar 30, 2012, at 7:13 PM, R?mi Forax wrote: > Hi guys, > I've played a little with Graal and I've some questions (a lot in fact but I will send several messages :) We're ready for your questions - fire away ;-) > First, I've deactivated the bootstrap code just because it was too painful > to wait before having the real code to be executed. I think the bootstrap should > be guarded by a static final not enabled by default. I've put a note in the (new) README_GRAAL.txt briefly describing Graal's bootstrap step as well as the -XX:-BootstrapGraal option that can be used to disable it. > Also a code in the hotspot directory was not compiling because my gcc emit a warning > when you shift a long (32bits) by 32, using a long long solve the issue. > See the diff at the end of this message. Thanks. I've applied your fix. > I also think you should add a README_GRAAL.txt at the root to explain > that to compile Graal , we have to use mx. Done. -Doug From doug.simon at oracle.com Mon Apr 2 04:38:40 2012 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 02 Apr 2012 11:38:40 +0000 Subject: hg: graal/graal: 2 new changesets Message-ID: <20120402113855.5964147C8C@hg.openjdk.java.net> Changeset: b97ef124c3ea Author: Doug Simon Date: 2012-04-02 11:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b97ef124c3ea added README_GRAAL.txt with simple build instructions + README_GRAAL.txt Changeset: 70aaaa83b93a Author: Doug Simon Date: 2012-04-02 12:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/70aaaa83b93a fixed gcc warning; added note to README_GRAAL about disabling the bootstrap step ! README_GRAAL.txt ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp From forax at univ-mlv.fr Tue Apr 3 02:59:18 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 03 Apr 2012 11:59:18 +0200 Subject: Graal - first step In-Reply-To: <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> Message-ID: <4F7AC9F6.5050702@univ-mlv.fr> On 04/02/2012 12:10 PM, Douglas Simon wrote: > Hi Remi, > > On Mar 30, 2012, at 7:13 PM, R?mi Forax wrote: > >> Hi guys, >> I've played a little with Graal and I've some questions (a lot in fact but I will send several messages :) > We're ready for your questions - fire away ;-) > >> First, I've deactivated the bootstrap code just because it was too painful >> to wait before having the real code to be executed. I think the bootstrap should >> be guarded by a static final not enabled by default. > I've put a note in the (new) README_GRAAL.txt briefly describing Graal's bootstrap step as well as the -XX:-BootstrapGraal option that can be used to disable it. Ok, thanks. > >> Also a code in the hotspot directory was not compiling because my gcc emit a warning >> when you shift a long (32bits) by 32, using a long long solve the issue. >> See the diff at the end of this message. > Thanks. I've applied your fix. Thanks again. > >> I also think you should add a README_GRAAL.txt at the root to explain >> that to compile Graal , we have to use mx. > Done. > > -Doug > R?mi From forax at univ-mlv.fr Tue Apr 3 03:10:00 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 03 Apr 2012 12:10:00 +0200 Subject: Graal - first step In-Reply-To: <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> Message-ID: <4F7ACC78.7030508@univ-mlv.fr> On 04/02/2012 12:10 PM, Douglas Simon wrote: > Hi Remi, > > On Mar 30, 2012, at 7:13 PM, R?mi Forax wrote: > >> Hi guys, >> I've played a little with Graal and I've some questions (a lot in fact but I will send several messages :) > We're ready for your questions - fire away ;-) I was exploring the idea to replace the bytecode backeend of a runtime like by example JRuby to construct a graph of graal's node. So please correct me if I'm wrong but I think it's not possible currently or possible in a very restricted way because each method need to be have a bytecode attached. By example, a deoptimize node will call a code in Hotspot that will trigger the interpreter so each method need a bytecode view. Another related problem is that there is currently no node that does profiling so I can't generate a graph of nodes with profile information that I will be able to extract using Graal interface with Hotspot. cheers, R?mi From forax at univ-mlv.fr Tue Apr 3 03:14:17 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 03 Apr 2012 12:14:17 +0200 Subject: Canonicalize array access In-Reply-To: <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> Message-ID: <4F7ACD79.1020808@univ-mlv.fr> On 04/02/2012 12:10 PM, Douglas Simon wrote: > Hi Remi, > > On Mar 30, 2012, at 7:13 PM, R?mi Forax wrote: > >> Hi guys, >> I've played a little with Graal and I've some questions (a lot in fact but I will send several messages :) > We're ready for your questions - fire away ;-) A small contribution. This code canonicalizes array access if the array and the index are a constant. cheers, R?mi diff --git a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadIndexedNode.java b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadIndexedNode.java --- a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadIndexedNode.java +++ b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadIndexedNode.java @@ -32,7 +32,7 @@ /** * The {@code LoadIndexedNode} represents a read from an element of an array. */ -public final class LoadIndexedNode extends AccessIndexedNode implements Lowerable, Node.IterableNodeType { +public final class LoadIndexedNode extends AccessIndexedNode implements Canonicalizable, Lowerable, Node.IterableNodeType { /** * Creates a new LoadIndexedNode. @@ -62,4 +62,17 @@ public void lower(CiLoweringTool tool) { tool.getRuntime().lower(this, tool); } + + @Override + public ValueNode canonical(CanonicalizerTool tool) { + if (index().isConstant() && array().isConstant() && !array().isNullConstant()) { + int arrayIndex = index().asConstant().asInt(); + CiConstant constArray = array().asConstant(); + if (arrayIndex >= 0 && arrayIndex < tool.runtime().getArrayLength(constArray)) { + CiConstant constant = elementKind().readUnsafeArrayConstant(constArray.asObject(), arrayIndex); + return ConstantNode.forCiConstant(constant, tool.runtime(), graph()); + } + } + return this; + } } diff --git a/graal/com.oracle.max.cri/src/com/oracle/max/cri/ci/CiKind.java b/graal/com.oracle.max.cri/src/com/oracle/max/cri/ci/CiKind.java --- a/graal/com.oracle.max.cri/src/com/oracle/max/cri/ci/CiKind.java +++ b/graal/com.oracle.max.cri/src/com/oracle/max/cri/ci/CiKind.java @@ -337,5 +337,33 @@ return null; } } + + public CiConstant readUnsafeArrayConstant(Object value, long index) { + assert value != null; + Unsafe u = Unsafe.getUnsafe(); + switch(this) { + case Boolean: + return CiConstant.forBoolean(u.getBoolean(value, Unsafe.ARRAY_BOOLEAN_BASE_OFFSET + index * Unsafe.ARRAY_BOOLEAN_INDEX_SCALE)); + case Byte: + return CiConstant.forByte(u.getByte(value, Unsafe.ARRAY_BYTE_BASE_OFFSET + index * Unsafe.ARRAY_BYTE_INDEX_SCALE)); + case Char: + return CiConstant.forChar(u.getChar(value, Unsafe.ARRAY_CHAR_BASE_OFFSET + index * Unsafe.ARRAY_CHAR_INDEX_SCALE)); + case Short: + return CiConstant.forShort(u.getShort(value, Unsafe.ARRAY_SHORT_BASE_OFFSET + index * Unsafe.ARRAY_SHORT_INDEX_SCALE)); + case Int: + return CiConstant.forInt(u.getInt(value, Unsafe.ARRAY_INT_BASE_OFFSET + index * Unsafe.ARRAY_INT_INDEX_SCALE)); + case Long: + return CiConstant.forLong(u.getLong(value, Unsafe.ARRAY_LONG_BASE_OFFSET + index * Unsafe.ARRAY_LONG_INDEX_SCALE)); + case Float: + return CiConstant.forFloat(u.getFloat(value, Unsafe.ARRAY_FLOAT_BASE_OFFSET + index * Unsafe.ARRAY_FLOAT_INDEX_SCALE)); + case Double: + return CiConstant.forDouble(u.getDouble(value, Unsafe.ARRAY_DOUBLE_BASE_OFFSET + index * Unsafe.ARRAY_DOUBLE_INDEX_SCALE)); + case Object: + return CiConstant.forObject(u.getObject(value, Unsafe.ARRAY_OBJECT_BASE_OFFSET + index * Unsafe.ARRAY_OBJECT_INDEX_SCALE)); + default: + assert false : "unexpected kind: " + this; + return null; + } + } } From forax at univ-mlv.fr Tue Apr 3 03:28:59 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 03 Apr 2012 12:28:59 +0200 Subject: Add a way to specify optimisitic optimizations when compiling using GraalRuntime In-Reply-To: <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> Message-ID: <4F7AD0EB.9000709@univ-mlv.fr> On 04/02/2012 12:10 PM, Douglas Simon wrote: > Hi Remi, > > On Mar 30, 2012, at 7:13 PM, R?mi Forax wrote: > >> Hi guys, >> I've played a little with Graal and I've some questions (a lot in fact but I will send several messages :) > We're ready for your questions - fire away ;-) Currently, there is no way to specify when compiling a method using GraalRuntime.compile() if the optimistic optimizations should be used or not. But sometime you don't want any optimistic optimizations at all, like by example when compiling an intrinsics. The patch below just add a new parameter to specify the optimistic optimizations. R?mi diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java @@ -449,11 +449,11 @@ } @Override - public CiTargetMethod compile(RiResolvedMethod method, StructuredGraph graph) { + public CiTargetMethod compile(RiResolvedMethod method, StructuredGraph graph, OptimisticOptimizations optimisticOpts) { final PhasePlan plan = new PhasePlan(); - GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(compiler.getRuntime(), GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.ALL); + GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(compiler.getRuntime(), GraphBuilderConfiguration.getDefault(), optimisticOpts); plan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); - return compiler.getCompiler().compileMethod(method, graph, -1, compiler.getCache(), plan, OptimisticOptimizations.ALL); + return compiler.getCompiler().compileMethod(method, graph, -1, compiler.getCache(), plan, optimisticOpts); } @Override diff --git a/graal/com.oracle.graal.nodes/src/com/oracle/graal/cri/GraalRuntime.java b/graal/com.oracle.graal.nodes/src/com/oracle/graal/cri/GraalRuntime.java --- a/graal/com.oracle.graal.nodes/src/com/oracle/graal/cri/GraalRuntime.java +++ b/graal/com.oracle.graal.nodes/src/com/oracle/graal/cri/GraalRuntime.java @@ -26,6 +26,7 @@ import com.oracle.max.cri.ci.*; import com.oracle.max.cri.ri.*; +import com.oracle.graal.compiler.OptimisticOptimizations; import com.oracle.graal.graph.*; import com.oracle.graal.nodes.*; @@ -38,7 +39,7 @@ StructuredGraph intrinsicGraph(RiResolvedMethod caller, int bci, RiResolvedMethod method, List parameters); - CiTargetMethod compile(RiResolvedMethod method, StructuredGraph graph); + CiTargetMethod compile(RiResolvedMethod method, StructuredGraph graph, OptimisticOptimizations optimisticOpts); long[] getDeoptedLeafGraphIds(); } From thomas.wuerthinger at oracle.com Tue Apr 3 07:47:25 2012 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 03 Apr 2012 16:47:25 +0200 Subject: Add a way to specify optimisitic optimizations when compiling using GraalRuntime In-Reply-To: <4F7AD0EB.9000709@univ-mlv.fr> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> <4F7AD0EB.9000709@univ-mlv.fr> Message-ID: <4F7B0D7D.8020005@oracle.com> Thanks for your third patch within a couple of days! You keep us quite busy here, which is great ;). - thomas On 03.04.2012 12:28, R?mi Forax wrote: > On 04/02/2012 12:10 PM, Douglas Simon wrote: >> Hi Remi, >> >> On Mar 30, 2012, at 7:13 PM, R?mi Forax wrote: >> >>> Hi guys, >>> I've played a little with Graal and I've some questions (a lot in >>> fact but I will send several messages :) >> We're ready for your questions - fire away ;-) > > Currently, there is no way to specify when compiling a method using > GraalRuntime.compile() > if the optimistic optimizations should be used or not. > But sometime you don't want any optimistic optimizations at all, like > by example when compiling an intrinsics. > > The patch below just add a new parameter to specify the optimistic > optimizations. > > R?mi > > diff --git > a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java > b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java > > --- > a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java > +++ > b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java > @@ -449,11 +449,11 @@ > } > > @Override > - public CiTargetMethod compile(RiResolvedMethod method, > StructuredGraph graph) { > + public CiTargetMethod compile(RiResolvedMethod method, > StructuredGraph graph, OptimisticOptimizations optimisticOpts) { > final PhasePlan plan = new PhasePlan(); > - GraphBuilderPhase graphBuilderPhase = new > GraphBuilderPhase(compiler.getRuntime(), > GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.ALL); > + GraphBuilderPhase graphBuilderPhase = new > GraphBuilderPhase(compiler.getRuntime(), > GraphBuilderConfiguration.getDefault(), optimisticOpts); > plan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); > - return compiler.getCompiler().compileMethod(method, graph, > -1, compiler.getCache(), plan, OptimisticOptimizations.ALL); > + return compiler.getCompiler().compileMethod(method, graph, > -1, compiler.getCache(), plan, optimisticOpts); > } > > @Override > diff --git > a/graal/com.oracle.graal.nodes/src/com/oracle/graal/cri/GraalRuntime.java > b/graal/com.oracle.graal.nodes/src/com/oracle/graal/cri/GraalRuntime.java > --- > a/graal/com.oracle.graal.nodes/src/com/oracle/graal/cri/GraalRuntime.java > +++ > b/graal/com.oracle.graal.nodes/src/com/oracle/graal/cri/GraalRuntime.java > @@ -26,6 +26,7 @@ > > import com.oracle.max.cri.ci.*; > import com.oracle.max.cri.ri.*; > +import com.oracle.graal.compiler.OptimisticOptimizations; > import com.oracle.graal.graph.*; > import com.oracle.graal.nodes.*; > > @@ -38,7 +39,7 @@ > > StructuredGraph intrinsicGraph(RiResolvedMethod caller, int bci, > RiResolvedMethod method, List parameters); > > - CiTargetMethod compile(RiResolvedMethod method, StructuredGraph > graph); > + CiTargetMethod compile(RiResolvedMethod method, StructuredGraph > graph, OptimisticOptimizations optimisticOpts); > > long[] getDeoptedLeafGraphIds(); > } > From thomas.wuerthinger at oracle.com Tue Apr 3 07:57:50 2012 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 03 Apr 2012 16:57:50 +0200 Subject: Graal - first step In-Reply-To: <4F7ACC78.7030508@univ-mlv.fr> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> <4F7ACC78.7030508@univ-mlv.fr> Message-ID: <4F7B0FEE.3070604@oracle.com> On 03.04.2012 12:10, R?mi Forax wrote: > On 04/02/2012 12:10 PM, Douglas Simon wrote: >> Hi Remi, >> >> On Mar 30, 2012, at 7:13 PM, R?mi Forax wrote: >> >>> Hi guys, >>> I've played a little with Graal and I've some questions (a lot in >>> fact but I will send several messages :) >> We're ready for your questions - fire away ;-) > > I was exploring the idea to replace the bytecode backeend of a runtime > like by example JRuby > to construct a graph of graal's node. > So please correct me if I'm wrong but I think it's not possible currently > or possible in a very restricted way because each method need to be > have a bytecode attached. > > By example, a deoptimize node will call a code in Hotspot that will > trigger the interpreter > so each method need a bytecode view. Yes. HotSpot forces us to always deoptimize to a valid bytecode position. We are currently working on a new abstraction layer on top of Graal that will remove this constraint. > Another related problem is that there is currently no node that does > profiling so > I can't generate a graph of nodes with profile information that I will > be able to extract > using Graal interface with Hotspot. It is possible to generate a node that will lower itself to a store/load to an object that is pointing to the profiling data. The Graal snippet mechanism would allow to specify the lowering in Java code (like we do with arraycopy intrinsification, see ArrayCopySnippets class). What kind of general-purpose interface would you suggest for weaving profiling code into the Graal IR? - thomas From jim.duey at gmail.com Tue Apr 3 13:17:00 2012 From: jim.duey at gmail.com (Jim Duey) Date: Tue, 03 Apr 2012 15:17:00 -0500 Subject: GraalVM on Snow Leopard Message-ID: <4F7B5ABC.3000809@gmail.com> Hi all. I'm just starting to look at the Graal compiler and I'm excited about the possibilities. In the OpenJDK project page, it mentions a requirement for OSX Lion. What's the reason for that? Is it strictly a need for Java 1.7? I got 1.7 installed on Snow Leopard and doing an "mx build" gives the following: Error: could not find libjava.dylib Error: Could not find Java SE Runtime Environment. *** An XSLT processor (J2SE 1.4.x or newer) is required to bootstrap this build Thanks, Jim From forax at univ-mlv.fr Tue Apr 3 14:47:36 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 03 Apr 2012 23:47:36 +0200 Subject: Add a way to specify optimisitic optimizations when compiling using GraalRuntime In-Reply-To: <4F7B0D7D.8020005@oracle.com> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> <4F7AD0EB.9000709@univ-mlv.fr> <4F7B0D7D.8020005@oracle.com> Message-ID: <4F7B6FF8.50003@univ-mlv.fr> On 04/03/2012 04:47 PM, Thomas Wuerthinger wrote: > Thanks for your third patch within a couple of days! You keep us quite > busy here, which is great ;). In fact, this patch introduces a kind of worm, it adds a dependency between graal.nodes and graal.compiler but graal.compiler also transitively depends on graal.nodes and the mx script seems not able to cope with circular dependencies :( I don't know if mx.py can be changed but the patch below fix the problem. > > - thomas R?mi diff --git a/mx/projects b/mx/projects --- a/mx/projects +++ b/mx/projects @@ -69,13 +69,6 @@ project at com.oracle.graal.snippets@checkstyle=com.oracle.graal.graph project at com.oracle.graal.snippets@javaCompliance=1.7 -# graal.nodes -project at com.oracle.graal.nodes@subDir=graal -project at com.oracle.graal.nodes@sourceDirs=src,test -project at com.oracle.graal.nodes@dependencies=com.oracle.max.cri,com.oracle.graal.graph -project at com.oracle.graal.nodes@checkstyle=com.oracle.graal.graph -project at com.oracle.graal.nodes@javaCompliance=1.7 - # graal.compiler project at com.oracle.graal.compiler@subDir=graal project at com.oracle.graal.compiler@sourceDirs=src @@ -83,6 +76,13 @@ project at com.oracle.graal.compiler@checkstyle=com.oracle.graal.graph project at com.oracle.graal.compiler@javaCompliance=1.7 +# graal.nodes +project at com.oracle.graal.nodes@subDir=graal +project at com.oracle.graal.nodes@sourceDirs=src,test +project at com.oracle.graal.nodes@dependencies=com.oracle.max.cri,com.oracle.graal.graph,com.oracle.graal.compiler +project at com.oracle.graal.nodes@checkstyle=com.oracle.graal.graph +project at com.oracle.graal.nodes@javaCompliance=1.7 + # graal.java project at com.oracle.graal.java@subDir=graal project at com.oracle.graal.java@sourceDirs=src diff --git a/mxtool/mx.py b/mxtool/mx.py --- a/mxtool/mx.py +++ b/mxtool/mx.py @@ -180,6 +180,8 @@ """ if self in deps: return deps + if includeSelf: + deps.append(self) for name in self.deps: assert name != self.name dep = _libs.get(name, None) @@ -190,8 +192,6 @@ dep = project(name) if not dep in deps: dep.all_deps(deps, includeLibs) - if not self in deps and includeSelf: - deps.append(self) return deps def _compute_max_dep_distances(self, name, distances, dist): From forax at univ-mlv.fr Tue Apr 3 15:16:30 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 04 Apr 2012 00:16:30 +0200 Subject: Graal - first step In-Reply-To: <4F7B0FEE.3070604@oracle.com> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> <4F7ACC78.7030508@univ-mlv.fr> <4F7B0FEE.3070604@oracle.com> Message-ID: <4F7B76BE.4040704@univ-mlv.fr> On 04/03/2012 04:57 PM, Thomas Wuerthinger wrote: > On 03.04.2012 12:10, R?mi Forax wrote: >> On 04/02/2012 12:10 PM, Douglas Simon wrote: >>> Hi Remi, >>> >>> On Mar 30, 2012, at 7:13 PM, R?mi Forax wrote: >>> >>>> Hi guys, >>>> I've played a little with Graal and I've some questions (a lot in >>>> fact but I will send several messages :) >>> We're ready for your questions - fire away ;-) >> >> I was exploring the idea to replace the bytecode backeend of a >> runtime like by example JRuby >> to construct a graph of graal's node. >> So please correct me if I'm wrong but I think it's not possible >> currently >> or possible in a very restricted way because each method need to be >> have a bytecode attached. >> >> By example, a deoptimize node will call a code in Hotspot that will >> trigger the interpreter >> so each method need a bytecode view. > Yes. HotSpot forces us to always deoptimize to a valid bytecode > position. We are currently working on a new abstraction layer on top > of Graal that will remove this constraint. Cool. Let me know if I can help. >> Another related problem is that there is currently no node that does >> profiling so >> I can't generate a graph of nodes with profile information that I >> will be able to extract >> using Graal interface with Hotspot. > It is possible to generate a node that will lower itself to a > store/load to an object that is pointing to the profiling data. The > Graal snippet mechanism would allow to specify the lowering in Java > code (like we do with arraycopy intrinsification, see > ArrayCopySnippets class). What kind of general-purpose interface would > you suggest for weaving profiling code into the Graal IR? I think some nodes like IfNode, SwitchNode, InstanceOfNode etc. should have a boolean asking for generating the record code, in order to record branch taken, type profile and exception seen. By example for IfNode, a boolean profileBranchTakenProbability will ask the code generator to generate the record code for each branch of the if. and as you said, a new phase should be introduced that will add new Nodes (using snippet) to generate the record code where it should be generated. > > - thomas R?mi From doug.simon at oracle.com Tue Apr 3 23:43:22 2012 From: doug.simon at oracle.com (Douglas Simon) Date: Wed, 4 Apr 2012 08:43:22 +0200 Subject: GraalVM on Snow Leopard In-Reply-To: <4F7B5ABC.3000809@gmail.com> References: <4F7B5ABC.3000809@gmail.com> Message-ID: <568B72A5-F814-40A6-9CB6-53BC16F49543@oracle.com> Hi Jim, On Apr 3, 2012, at 10:17 PM, Jim Duey wrote: > Hi all. > > I'm just starting to look at the Graal compiler and I'm excited about the possibilities. > > In the OpenJDK project page, it mentions a requirement for OSX Lion. What's the reason for that? Is it strictly a need for Java 1.7? Java 1.7 is definitely a requirement for Graal. As to whether it works with Snow Leopard, I don't know as I've never tried it. > I got 1.7 installed on Snow Leopard I was not aware this was possible for the latest official builds of Mac preview release (http://jdk7.java.net/macportpreview/). What version are you using? On my machine, the output of 'java -version' is: java version "1.7.0_04-ea" Java(TM) SE Runtime Environment (build 1.7.0_04-ea-b17) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b18, mixed mode) > and doing an "mx build" gives the following: > > Error: could not find libjava.dylib > > Error: Could not find Java SE Runtime Environment. > > *** An XSLT processor (J2SE 1.4.x or newer) is required to bootstrap this build If you send me the output of the following command, I may be able to help. mx -v build --no-java -c -Doug From doug.simon at oracle.com Tue Apr 3 23:48:34 2012 From: doug.simon at oracle.com (Douglas Simon) Date: Wed, 4 Apr 2012 08:48:34 +0200 Subject: Add a way to specify optimisitic optimizations when compiling using GraalRuntime In-Reply-To: <4F7B6FF8.50003@univ-mlv.fr> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> <4F7AD0EB.9000709@univ-mlv.fr> <4F7B0D7D.8020005@oracle.com> <4F7B6FF8.50003@univ-mlv.fr> Message-ID: <0181D3D9-6696-4400-9648-64B9E2E4698D@oracle.com> On Apr 3, 2012, at 11:47 PM, R?mi Forax wrote: > On 04/03/2012 04:47 PM, Thomas Wuerthinger wrote: >> Thanks for your third patch within a couple of days! You keep us quite busy here, which is great ;). > > In fact, this patch introduces a kind of worm, it adds a dependency between graal.nodes > and graal.compiler but graal.compiler also transitively depends on graal.nodes > and the mx script seems not able to cope with circular dependencies :( That is an explicit design decision. Circular dependencies are heavily discouraged! ;-) Maybe you can explain why you need a dependency from graal.nodes to graal.compiler and we can suggest another way to solve the issue. -Doug > > diff --git a/mx/projects b/mx/projects > --- a/mx/projects > +++ b/mx/projects > @@ -69,13 +69,6 @@ > project at com.oracle.graal.snippets@checkstyle=com.oracle.graal.graph > project at com.oracle.graal.snippets@javaCompliance=1.7 > > -# graal.nodes > -project at com.oracle.graal.nodes@subDir=graal > -project at com.oracle.graal.nodes@sourceDirs=src,test > -project at com.oracle.graal.nodes@dependencies=com.oracle.max.cri,com.oracle.graal.graph > -project at com.oracle.graal.nodes@checkstyle=com.oracle.graal.graph > -project at com.oracle.graal.nodes@javaCompliance=1.7 > - > # graal.compiler > project at com.oracle.graal.compiler@subDir=graal > project at com.oracle.graal.compiler@sourceDirs=src > @@ -83,6 +76,13 @@ > project at com.oracle.graal.compiler@checkstyle=com.oracle.graal.graph > project at com.oracle.graal.compiler@javaCompliance=1.7 > > +# graal.nodes > +project at com.oracle.graal.nodes@subDir=graal > +project at com.oracle.graal.nodes@sourceDirs=src,test > +project at com.oracle.graal.nodes@dependencies=com.oracle.max.cri,com.oracle.graal.graph,com.oracle.graal.compiler > +project at com.oracle.graal.nodes@checkstyle=com.oracle.graal.graph > +project at com.oracle.graal.nodes@javaCompliance=1.7 > + > # graal.java > project at com.oracle.graal.java@subDir=graal > project at com.oracle.graal.java@sourceDirs=src > diff --git a/mxtool/mx.py b/mxtool/mx.py > --- a/mxtool/mx.py > +++ b/mxtool/mx.py > @@ -180,6 +180,8 @@ > """ > if self in deps: > return deps > + if includeSelf: > + deps.append(self) > for name in self.deps: > assert name != self.name > dep = _libs.get(name, None) > @@ -190,8 +192,6 @@ > dep = project(name) > if not dep in deps: > dep.all_deps(deps, includeLibs) > - if not self in deps and includeSelf: > - deps.append(self) > return deps > > def _compute_max_dep_distances(self, name, distances, dist): > From forax at univ-mlv.fr Wed Apr 4 01:41:30 2012 From: forax at univ-mlv.fr (=?utf-8?B?UmVtaSBGb3JheA==?=) Date: Wed, 04 Apr 2012 10:41:30 +0200 Subject: =?utf-8?B?UmU6IEFkZCBhIHdheSB0byBzcGVjaWZ5IG9wdGltaXNpdGljIG9wdGltaXphdGlvbnMgd2hlbiBjb21waWxpbmcgdXNpbmcgR3JhYWxSdW50aW1l?= Message-ID: <201204040841.q348fS2O023702@monge.univ-mlv.fr> OptimisticOptimization is defined in graal.compiler and GraalRuntime in Graal.nodes. Because I think that GraalRuntime.compile should take a supplementary parameter specifying optimistic optimizations (see my previous mail) this will introduce a circular dependency. The other solution is to move OptimisticOpts in another module. R?mi Sent from my Phone ----- Reply message ----- From: "Douglas Simon" To: "R?mi Forax" Cc: "Thomas Wuerthinger" , Subject: Add a way to specify optimisitic optimizations when compiling using GraalRuntime Date: Wed, Apr 4, 2012 08:48 On Apr 3, 2012, at 11:47 PM, R?mi Forax wrote: > On 04/03/2012 04:47 PM, Thomas Wuerthinger wrote: >> Thanks for your third patch within a couple of days! You keep us quite busy here, which is great ;). > > In fact, this patch introduces a kind of worm, it adds a dependency between graal.nodes > and graal.compiler but graal.compiler also transitively depends on graal.nodes > and the mx script seems not able to cope with circular dependencies :( That is an explicit design decision. Circular dependencies are heavily discouraged! ;-) Maybe you can explain why you need a dependency from graal.nodes to graal.compiler and we can suggest another way to solve the issue. -Doug > > diff --git a/mx/projects b/mx/projects > --- a/mx/projects > +++ b/mx/projects > @@ -69,13 +69,6 @@ > project at com.oracle.graal.snippets@checkstyle=com.oracle.graal.graph > project at com.oracle.graal.snippets@javaCompliance=1.7 > > -# graal.nodes > -project at com.oracle.graal.nodes@subDir=graal > -project at com.oracle.graal.nodes@sourceDirs=src,test > -project at com.oracle.graal.nodes@dependencies=com.oracle.max.cri,com.oracle.graal.graph > -project at com.oracle.graal.nodes@checkstyle=com.oracle.graal.graph > -project at com.oracle.graal.nodes@javaCompliance=1.7 > - > # graal.compiler > project at com.oracle.graal.compiler@subDir=graal > project at com.oracle.graal.compiler@sourceDirs=src > @@ -83,6 +76,13 @@ > project at com.oracle.graal.compiler@checkstyle=com.oracle.graal.graph > project at com.oracle.graal.compiler@javaCompliance=1.7 > > +# graal.nodes > +project at com.oracle.graal.nodes@subDir=graal > +project at com.oracle.graal.nodes@sourceDirs=src,test > +project at com.oracle.graal.nodes@dependencies=com.oracle.max.cri,com.oracle.graal.graph,com.oracle.graal.compiler > +project at com.oracle.graal.nodes@checkstyle=com.oracle.graal.graph > +project at com.oracle.graal.nodes@javaCompliance=1.7 > + > # graal.java > project at com.oracle.graal.java@subDir=graal > project at com.oracle.graal.java@sourceDirs=src > diff --git a/mxtool/mx.py b/mxtool/mx.py > --- a/mxtool/mx.py > +++ b/mxtool/mx.py > @@ -180,6 +180,8 @@ > """ > if self in deps: > return deps > + if includeSelf: > + deps.append(self) > for name in self.deps: > assert name != self.name > dep = _libs.get(name, None) > @@ -190,8 +192,6 @@ > dep = project(name) > if not dep in deps: > dep.all_deps(deps, includeLibs) > - if not self in deps and includeSelf: > - deps.append(self) > return deps > > def _compute_max_dep_distances(self, name, distances, dist): > From thomas.wuerthinger at oracle.com Wed Apr 4 02:23:29 2012 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 04 Apr 2012 11:23:29 +0200 Subject: Graal - first step In-Reply-To: <4F7B76BE.4040704@univ-mlv.fr> References: <4F75E9B1.20106@univ-mlv.fr> <47726211-40B4-452D-A61C-7AF5C5274E8A@oracle.com> <4F7ACC78.7030508@univ-mlv.fr> <4F7B0FEE.3070604@oracle.com> <4F7B76BE.4040704@univ-mlv.fr> Message-ID: <4F7C1311.4020408@oracle.com> On 04.04.2012 00:16, R?mi Forax wrote: >>> Another related problem is that there is currently no node that does >>> profiling so >>> I can't generate a graph of nodes with profile information that I >>> will be able to extract >>> using Graal interface with Hotspot. >> It is possible to generate a node that will lower itself to a >> store/load to an object that is pointing to the profiling data. The >> Graal snippet mechanism would allow to specify the lowering in Java >> code (like we do with arraycopy intrinsification, see >> ArrayCopySnippets class). What kind of general-purpose interface >> would you suggest for weaving profiling code into the Graal IR? > > I think some nodes like IfNode, SwitchNode, InstanceOfNode etc. should > have a boolean > asking for generating the record code, in order to record branch taken, > type profile and exception seen. > By example for IfNode, a boolean profileBranchTakenProbability will ask > the code generator to generate the record code for each branch of the if. > > and as you said, a new phase should be introduced that will add new > Nodes (using snippet) > to generate the record code where it should be generated. We could add a phase that automatically inserts such code on every control split. What is the format / Java data structure in which you would like to have it recorded? - thomas From forax at univ-mlv.fr Wed Apr 4 04:33:07 2012 From: forax at univ-mlv.fr (=?utf-8?B?UmVtaSBGb3JheA==?=) Date: Wed, 04 Apr 2012 13:33:07 +0200 Subject: =?utf-8?B?UmU6IEdyYWFsIC0gZmlyc3Qgc3RlcA==?= Message-ID: <201204041133.q34BX2ij030797@monge.univ-mlv.fr> The decision to profile or not should not be a global decision. Let's take an example, delayed de-visualization. Language like scalable or java8 allows to write high order functions that by example loop over a collection of items and call a block of code for each element. From a VM point of view the call to the block of code is megamorphic. One way to devirtualize it is to let the interpreter to profile the code so we will have enough information to find which concrete high order function is called thus be able to inline it but instead of generating only a vtable call for the block call one can also add a code that will profile the type again. Because the code was inclined, the block call is not megamorphic anymore and a second generation will be able to fully online the high order function call at callsite. So deciding to insert profiling information should not be done globally. R?mi Sent from my Phone ----- Reply message ----- From: "Thomas Wuerthinger" To: "R?mi Forax" Cc: Subject: Graal - first step Date: Wed, Apr 4, 2012 11:23 On 04.04.2012 00:16, R?mi Forax wrote: >>> Another related problem is that there is currently no node that does >>> profiling so >>> I can't generate a graph of nodes with profile information that I >>> will be able to extract >>> using Graal interface with Hotspot. >> It is possible to generate a node that will lower itself to a >> store/load to an object that is pointing to the profiling data. The >> Graal snippet mechanism would allow to specify the lowering in Java >> code (like we do with arraycopy intrinsification, see >> ArrayCopySnippets class). What kind of general-purpose interface >> would you suggest for weaving profiling code into the Graal IR? > > I think some nodes like IfNode, SwitchNode, InstanceOfNode etc. should > have a boolean > asking for generating the record code, in order to record branch taken, > type profile and exception seen. > By example for IfNode, a boolean profileBranchTakenProbability will ask > the code generator to generate the record code for each branch of the if. > > and as you said, a new phase should be introduced that will add new > Nodes (using snippet) > to generate the record code where it should be generated. We could add a phase that automatically inserts such code on every control split. What is the format / Java data structure in which you would like to have it recorded? - thomas From doug.simon at oracle.com Sat Apr 7 18:02:43 2012 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 08 Apr 2012 01:02:43 +0000 Subject: hg: graal/graal: 27 new changesets Message-ID: <20120408010419.4F2A647F42@hg.openjdk.java.net> Changeset: e1e681a5558e Author: Lukas Stadler Date: 2012-04-02 19:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e1e681a5558e fix PriorityQueue, enable PriorityQueue and CacheGraphs ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/EscapeField.java ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/runtime/globals.hpp Changeset: d5cf399e6637 Author: Lukas Stadler Date: 2012-04-02 19:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d5cf399e6637 disable PriorityQueue and CacheGraphs ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalOptions.java ! src/share/vm/runtime/globals.hpp Changeset: db2286df9149 Author: Doug Simon Date: 2012-04-03 09:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/db2286df9149 made Logger thread-safe by using a ThreadLocal ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/logging/Logger.java Changeset: b00e56aa159d Author: Doug Simon Date: 2012-04-03 10:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b00e56aa159d added printing of HotSpot config if graal.printconfig system property is true ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/logging/Logger.java Changeset: 9b8c0d1bc2dd Author: Doug Simon Date: 2012-04-03 10:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9b8c0d1bc2dd unsafe load/store snippets now require a displacement argument which allows x86 complex addressing modes to be used for tighter encoding of array store/load operations replaced ArrayHeaderSizeNode with an arrayHeaderSizeFor(CiKind elementKind) method annotated by @Fold ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/snippets/ArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/snippets/UnsafeSnippets.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeLoadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java ! graal/com.oracle.graal.snippets/src/com/oracle/graal/snippets/NodeClassSnippets.java - graal/com.oracle.graal.snippets/src/com/oracle/graal/snippets/nodes/ArrayHeaderSizeNode.java Changeset: c49f9f0b9aad Author: Doug Simon Date: 2012-04-03 10:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c49f9f0b9aad Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java Changeset: 6fbf12b8e572 Author: Doug Simon Date: 2012-04-03 21:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6fbf12b8e572 automated download of hsdis lib if PrintAssembly option is used; added support for hsdis on the Mac ! mx/commands.py ! mxtool/mx.py Changeset: cb3245503a5e Author: Doug Simon Date: 2012-04-03 23:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cb3245503a5e emit GC write barrier for UnsafeStoreNode only if store kind is Object ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java Changeset: 67f52d18d01f Author: Doug Simon Date: 2012-04-03 23:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/67f52d18d01f revived mechanism for disabling automatic native builds in Eclipse ! hotspot/.project Changeset: 20993edddd73 Author: Doug Simon Date: 2012-04-04 09:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/20993edddd73 write barrier for UnsafeStoreNode must be inserted after associated write node has replaced original store node in the graph ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java Changeset: 02da376dd213 Author: Doug Simon Date: 2012-04-04 12:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/02da376dd213 abstracted word size in object array copy ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/snippets/ArrayCopySnippets.java Changeset: a6eceb5efb0e Author: Doug Simon Date: 2012-04-05 22:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a6eceb5efb0e added --ecl option to mx for saving VM execution(s) as Eclipse launch configurations ! .hgignore ! mx/commands.py ! mxtool/mx.py Changeset: 8125c1f6472b Author: Gilles Duboscq Date: 2012-04-05 17:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8125c1f6472b Add DaCapo 1st run as a benchmark group ! mx/commands.py ! mx/sanitycheck.py Changeset: beb13d0326ba Author: Gilles Duboscq Date: 2012-04-06 14:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/beb13d0326ba make DaCapo benchmark matchers produce multiple result lines ! mx/sanitycheck.py Changeset: e91f0761c56d Author: Gilles Duboscq Date: 2012-04-06 14:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e91f0761c56d Merge ! mx/commands.py Changeset: 887b45f6aa02 Author: Doug Simon Date: 2012-04-06 17:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/887b45f6aa02 improved name of Eclipse launch file created for jar applications converted IDE configuration generation to use XML class ! mxtool/mx.py Changeset: b968b71e22a4 Author: Gilles Duboscq Date: 2012-04-06 14:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b968b71e22a4 Allow tracking nodes responsible for a non-empty liveIn in LinearScan ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 2f31efbd60ac Author: Gilles Duboscq Date: 2012-04-06 14:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2f31efbd60ac Add a few loop jtts + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/loop/Loop15.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/loop/Loop16.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/loop/Loop17.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/loop/LoopLastIndexOf.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/loop/LoopParseLong.java Changeset: 891399c54706 Author: Gilles Duboscq Date: 2012-04-06 15:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/891399c54706 Add a PrintBailout option ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java Changeset: 450af990078f Author: Gilles Duboscq Date: 2012-04-06 15:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/450af990078f Fix for IntegerMul canonicalization : use the proper kind when canonicalizing a*0 Add a verify method for VirtualObjectFieldNode Make CFGVerifier check that the only loop entry is the loop header ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/cfg/CFGVerifier.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerMulNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessIndexedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualObjectFieldNode.java Changeset: 09e87f5b81e4 Author: Gilles Duboscq Date: 2012-04-06 15:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/09e87f5b81e4 Fix potential KillCFG problem Handle VirtualObjectField and VirtualObject better in killCFG ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java Changeset: 0a53ed842cb8 Author: Gilles Duboscq Date: 2012-04-06 16:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a53ed842cb8 Reordering and adjustments to phases ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java Changeset: d753f4cdba25 Author: Gilles Duboscq Date: 2012-04-06 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d753f4cdba25 Fix for EscapeAnalysis at loopEnds ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/EscapeAnalysisPhase.java Changeset: dfe925845cad Author: Gilles Duboscq Date: 2012-04-06 17:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dfe925845cad Improve exacuation of anchored values, use it to fix if and merge simplifications ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java Changeset: b1f3593bc718 Author: Gilles Duboscq Date: 2012-04-06 17:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b1f3593bc718 Merge Changeset: ae5504e366df Author: Gilles Duboscq Date: 2012-04-06 17:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae5504e366df Allow VirtualPhis in FrameStates, now the Virtual state in a LoopBegin's FrameState is the VirtualLoopPhi ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/EscapeAnalysisPhase.java Changeset: 7378314d3e06 Author: Gilles Duboscq Date: 2012-04-06 17:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7378314d3e06 Merge From jim.duey at gmail.com Tue Apr 10 08:11:56 2012 From: jim.duey at gmail.com (Jim Duey) Date: Tue, 10 Apr 2012 10:11:56 -0500 Subject: GraalVM on Snow Leopard In-Reply-To: <4F7B5ABC.3000809@gmail.com> References: <4F7B5ABC.3000809@gmail.com> Message-ID: <4F844DBC.9000709@gmail.com> Doug, I can't find the link now, but there were instructions on installing Java 7 on Snow Leopard and it went pretty easy. The failure with graal is that the install doesn't include JavaDB. So I punted on that issue and installed a Linux VirtualBox to do my work on. That's working fine. Jim From jim.duey at gmail.com Tue Apr 10 08:15:24 2012 From: jim.duey at gmail.com (Jim Duey) Date: Tue, 10 Apr 2012 10:15:24 -0500 Subject: LoopBeginNode Message-ID: <4F844E8C.7030602@gmail.com> Hi all, In the com.oracl.graal.nodes.LoopBeginNode class, there's a field named nextEndIndex. There's also a method of the same name, except that every time it's called, it increments the field. That seems like it mixes two different things; getting the value and incrementing it. Which may be totally acceptable in the way it's used, but it seems strange to me. Jim From doug.simon at oracle.com Sat Apr 14 18:03:21 2012 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 15 Apr 2012 01:03:21 +0000 Subject: hg: graal/graal: 35 new changesets Message-ID: <20120415010522.C9936470C5@hg.openjdk.java.net> Changeset: e3e7542d78b7 Author: Gilles Duboscq Date: 2012-04-09 19:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e3e7542d78b7 Loop-closed form GraphBuidling ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/EscapeAnalysisPhase.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/RemoveValueProxyPhase.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/SnippetIntrinsificationPhase.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/schedule/SchedulePhase.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/util/InliningUtil.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/cfg/ControlFlowGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopExitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/EscapeOp.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java Changeset: e9a7e097dbec Author: Gilles Duboscq Date: 2012-04-09 19:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e9a7e097dbec Fix for getModifiers intrinsic : use a floating read instead of floating a normal read ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java Changeset: b3533c2e6adf Author: Gilles Duboscq Date: 2012-04-09 19:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b3533c2e6adf Fix StoreIndexedNode lowering : use a FloatinReadNode instead of Floating a ReadNode Add a verify method to FixedNode : FixedNodes should be fixed ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedNode.java Changeset: 3a41de0ebbfb Author: Gilles Duboscq Date: 2012-04-09 19:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3a41de0ebbfb We can use a FloatingRead to get the arrayClass in storechecks ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java Changeset: 1020e363a05d Author: Gilles Duboscq Date: 2012-04-09 19:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1020e363a05d Loop peeling ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/loop/LoopTransformDataResolver.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/loop/LoopTransformUtil.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/loop/SuperBlock.java + graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LoopTransformPhase.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/cfg/Loop.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java Changeset: ae367987a18c Author: Gilles Duboscq Date: 2012-04-09 20:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae367987a18c Add options for OptLoopTransform and OptSafepointElimination ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalOptions.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/loop/SuperBlock.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LoopTransformPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java Changeset: b64933dc4830 Author: Gilles Duboscq Date: 2012-04-09 20:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b64933dc4830 Peeling loop depending on their entry probability ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalOptions.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LoopTransformPhase.java Changeset: 70777e50f1e6 Author: Doug Simon Date: 2012-04-08 00:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/70777e50f1e6 replace monkey patch with subclassing instead ! mxtool/mx.py Changeset: c4696edb6e95 Author: Doug Simon Date: 2012-04-10 12:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c4696edb6e95 Merge. Changeset: ddccd4abdb09 Author: Doug Simon Date: 2012-04-10 12:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ddccd4abdb09 configured test source directory for graal.graph project ! graal/com.oracle.graal.graph/test/com/oracle/graal/graph/test/TypedNodeIteratorTest.java ! mx/projects ! mxtool/mx.py Changeset: a9e4b30968d4 Author: Gilles Duboscq Date: 2012-04-10 14:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a9e4b30968d4 Estimate size of loop and peel only if resulting graph is not too big ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/loop/LoopTransformUtil.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LoopTransformPhase.java Changeset: d066f83db303 Author: Gilles Duboscq Date: 2012-04-10 14:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d066f83db303 Merge Changeset: 155f8ca28f11 Author: Gilles Duboscq Date: 2012-04-10 15:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/155f8ca28f11 Fix for peeling : fix a bug in the Virtual chain reconstruction ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/loop/SuperBlock.java Changeset: c4381dacfca6 Author: Andreas Woess Date: 2012-04-10 18:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c4381dacfca6 Add peel method overload with SuperBlock parameter. Don't call normalizeLoopBegin. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/loop/LoopTransformUtil.java Changeset: e706b132f580 Author: Andreas Woess Date: 2012-04-10 18:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e706b132f580 Merge ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/loop/LoopTransformUtil.java Changeset: a693408f737c Author: Andreas Woess Date: 2012-04-10 19:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a693408f737c Merge node simplification: Combine merge cascades into a single merge. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java Changeset: 51d2cac7db70 Author: Gilles Duboscq Date: 2012-04-11 10:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51d2cac7db70 Cosmetic fix to bailout output ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java Changeset: 6b1170c32a81 Author: Gilles Duboscq Date: 2012-04-11 10:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b1170c32a81 Merge Changeset: e0f17fb3e7d2 Author: Gilles Duboscq Date: 2012-04-11 11:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e0f17fb3e7d2 Do not split merges when they are used to anchor some values ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java Changeset: ce6cb3a1eb44 Author: Gilles Duboscq Date: 2012-04-11 15:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ce6cb3a1eb44 mx dacapo, mx scaladacapo and mx specjvm2008 should use the specified vm ! mx/commands.py Changeset: 333930100018 Author: Doug Simon Date: 2012-04-11 12:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/333930100018 enhanced disassembly to decode stub addresses for runtime calls ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java Changeset: 7564f0469116 Author: Doug Simon Date: 2012-04-11 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7564f0469116 added links to SPARC directories to enable browsing alternative backend details ! hotspot/.project Changeset: c005ca943790 Author: Doug Simon Date: 2012-04-12 14:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c005ca943790 added -j option to gate command to disable cleaning of Java class files ! mx/commands.py Changeset: efbb1e33e2f3 Author: Doug Simon Date: 2012-04-12 15:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/efbb1e33e2f3 removed XIR prologue and epilogues - architecture and runtime specific subclass of Backend is now used instead removed XIR ops: Align, StackOverflowCheck, PushFrame, PopFrame, RawBytes enhanced disassembly to annotate marks ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/amd64/AMD64Backend.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/amd64/AMD64DeoptimizationStub.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/amd64/AMD64LIRGenerator.java - graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/amd64/AMD64MethodEndStub.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/amd64/AMD64XirAssembler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/amd64/AMD64XirOp.java ! graal/com.oracle.graal.examples/src/examples/HelloWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotXirGenerator.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/target/amd64/HotSpotAMD64Backend.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java + graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Code.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ControlFlow.java - graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SlowPath.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java + graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/FrameContext.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/cri/GraalRuntime.java ! graal/com.oracle.max.asm/src/com/oracle/max/asm/AbstractAssembler.java ! graal/com.oracle.max.asm/src/com/oracle/max/asm/target/amd64/AMD64Assembler.java ! graal/com.oracle.max.cri/src/com/oracle/max/cri/xir/CiXirAssembler.java ! graal/com.oracle.max.cri/src/com/oracle/max/cri/xir/RiXirGenerator.java Changeset: c1e5e3ab546d Author: Doug Simon Date: 2012-04-12 15:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c1e5e3ab546d Merge. ! mx/commands.py Changeset: 15c857decc43 Author: Doug Simon Date: 2012-04-12 17:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/15c857decc43 fixed bug in call to unwindExceptionStub (exceptionOop arg was not be passed correctly) removed one use of scratch register abstraction ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/target/amd64/HotSpotAMD64Backend.java Changeset: f9aae727d035 Author: Doug Simon Date: 2012-04-12 20:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9aae727d035 removed XIR safepoint operation ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotXirGenerator.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/target/amd64/AMD64SafepointOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/target/amd64/HotSpotAMD64Backend.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java ! graal/com.oracle.max.cri/src/com/oracle/max/cri/xir/RiXirGenerator.java Changeset: 8c7e786886d0 Author: Doug Simon Date: 2012-04-12 20:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c7e786886d0 made links to CPU and OS specific directories shorter ! hotspot/.project Changeset: cce31bc56c00 Author: Doug Simon Date: 2012-04-13 11:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cce31bc56c00 made HotSpotResolvedMethodImpl.toStackTraceElement() call into native code to get an object containing source file info ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotMethodResolvedImpl.java ! graal/com.oracle.max.cri/src/com/oracle/max/cri/ci/CiUtil.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: b9db4fee6eb2 Author: Doug Simon Date: 2012-04-13 15:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b9db4fee6eb2 skip a native build if all files in src and make are older than the timestamp of the previous build ! mx/commands.py ! mxtool/mx.py Changeset: ec177db4a412 Author: Doug Simon Date: 2012-04-13 15:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ec177db4a412 fixed incorrect register arg in graal_create_out_of_bounds_exception stub ! src/cpu/x86/vm/c1_Runtime1_x86.cpp Changeset: e24167877471 Author: Doug Simon Date: 2012-04-13 15:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e24167877471 conditional support for translating ExceptionObjectNode without XIR + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotExceptionObject.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java Changeset: f46d82be6e19 Author: Doug Simon Date: 2012-04-13 23:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f46d82be6e19 ExceptionObjectNode is now lowered without XIR ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LoweringPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotExceptionObjectNode.java < graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotExceptionObject.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotXirGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/target/amd64/HotSpotAMD64Backend.java ! graal/com.oracle.max.cri/src/com/oracle/max/cri/xir/RiXirGenerator.java Changeset: e954395cc873 Author: Doug Simon Date: 2012-04-13 23:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e954395cc873 fixed bug in BitMap.negate() causing length() to be greater than size() ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/BitMap.java Changeset: 55ff4ba8d7b1 Author: Doug Simon Date: 2012-04-13 23:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/55ff4ba8d7b1 ignore src/share/tools directory in native build out-of-date check ! mx/commands.py From doug.simon at oracle.com Sat Apr 21 18:03:20 2012 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 22 Apr 2012 01:03:20 +0000 Subject: hg: graal/graal: 26 new changesets Message-ID: <20120422010452.32E2C471FD@hg.openjdk.java.net> Changeset: 71ac4221b1b0 Author: Doug Simon Date: 2012-04-17 13:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/71ac4221b1b0 added hcfdis command ! mx/commands.py Changeset: 8bf2c37c46c4 Author: Doug Simon Date: 2012-04-17 13:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8bf2c37c46c4 added RiCompiledMethod.executeVarargs(Object...) to support compiling and calling arbitrary Java methods ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotCompiledMethod.java ! graal/com.oracle.graal.tests/src/com/oracle/graal/compiler/tests/CompiledMethodTest.java ! graal/com.oracle.max.cri/src/com/oracle/max/cri/ri/RiCompiledMethod.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 62bbfd78c703 Author: Doug Simon Date: 2012-04-17 22:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/62bbfd78c703 removed mechanism for lowering ExceptionObjectNode via substitution; only LIR lowering by the runtime is now supported ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LoweringPhase.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/amd64/AMD64LIRGenerator.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotExceptionObjectNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotMethodResolvedImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java Changeset: 066f1687ba24 Author: Doug Simon Date: 2012-04-18 13:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/066f1687ba24 rename: nodesFor -> blockToNodesMap ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/schedule/SchedulePhase.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/types/PropagateTypeCachePhase.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.tests/src/com/oracle/graal/compiler/tests/TypeSystemTest.java Changeset: 2d26d5ca2e5b Author: Doug Simon Date: 2012-04-18 17:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2d26d5ca2e5b give machine code printed by the CFGPrinterObserver a cfg context so that does not depend on the LIR also being printed ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java Changeset: 0f6f647e8a96 Author: Doug Simon Date: 2012-04-18 23:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0f6f647e8a96 bug fix: can only use HotSpot code for constructing a StackTraceElement when the bci is valid ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/ri/HotSpotMethodResolvedImpl.java Changeset: 467de393651a Author: Doug Simon Date: 2012-04-18 23:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/467de393651a optimization: frame prologue & epilogue ommitted for methods with no spills, no callee-saved registers, no incoming stack args and no debug info ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/target/amd64/HotSpotAMD64Backend.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ControlFlow.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/FrameContext.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/graal/graalEnv.cpp Changeset: 1a9a048386d6 Author: Doug Simon Date: 2012-04-19 16:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1a9a048386d6 added JRE to source path in generated Eclipse launches ! mxtool/mx.py Changeset: e8e1278101d9 Author: Doug Simon Date: 2012-04-19 22:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e8e1278101d9 stack overflow check is now commented in disassembly ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java Changeset: 9c2b6cc9de45 Author: Doug Simon Date: 2012-04-19 22:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c2b6cc9de45 removed creation of unused context snapshot ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/IdealGraphPrinterDumpHandler.java Changeset: 38feba3e8526 Author: Doug Simon Date: 2012-04-19 22:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/38feba3e8526 separated safepoints out of LoopEndNodes into SafepointNodes ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/SafepointPollingEliminationPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/target/amd64/HotSpotAMD64Backend.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopEndNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SafepointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java ! graal/com.oracle.graal.snippets/src/com/oracle/graal/snippets/Snippets.java Changeset: 1e153fdac9fb Author: Christian Wimmer Date: 2012-04-19 17:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1e153fdac9fb Fix and simplify exception handling in the bytecode parser ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: a549662f6c6f Author: Doug Simon Date: 2012-04-20 14:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a549662f6c6f added 'vmg' and 'vmfg' commands to mx as convenient aliases for running the debug and fastdebug builds of the selected VM ! mx/commands.py Changeset: 97b1e0ab7442 Author: Doug Simon Date: 2012-04-20 14:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97b1e0ab7442 added javadoc to some of the API for removing nodes from a graph ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java Changeset: af8958fe5a3a Author: Doug Simon Date: 2012-04-20 14:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af8958fe5a3a removed unwind stub from Graal compiled methods as it is only used by C1 ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/target/amd64/HotSpotAMD64Backend.java ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 4e4a868c2b2a Author: Doug Simon Date: 2012-04-20 14:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4e4a868c2b2a Merge. Changeset: 6cd293b125ea Author: Doug Simon Date: 2012-04-20 14:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6cd293b125ea added assertion to prevent @Data being applied to a field of type Node ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: a6632d6e2753 Author: Doug Simon Date: 2012-04-20 14:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a6632d6e2753 removed data link from SafepointNode to a LoopEndNode ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/SafepointNode.java Changeset: d87155082c4d Author: Lukas Stadler Date: 2012-04-13 15:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d87155082c4d guard all compilation queue accesses, to avoid deadlocks ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 9fe76535501f Author: Lukas Stadler Date: 2012-04-19 14:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9fe76535501f make non-empty liveIn set of first block a fatal GraalInternalError ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: b8661be84cfd Author: Lukas Stadler Date: 2012-04-19 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b8661be84cfd fix "mx intro" ! mx/commands.py Changeset: c9dd4054c23b Author: Lukas Stadler Date: 2012-04-20 13:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c9dd4054c23b Merge ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 8191f71d7f51 Author: Lukas Stadler Date: 2012-04-20 13:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8191f71d7f51 Merge Changeset: b59e32ea3761 Author: Lukas Stadler Date: 2012-04-20 15:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b59e32ea3761 enable graph caching and priority compilation queue ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalOptions.java ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/share/vm/runtime/globals.hpp Changeset: 6b2d030d01ff Author: Lukas Stadler Date: 2012-04-20 15:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b2d030d01ff Merge ! mx/commands.py Changeset: e7f3f0541429 Author: Lukas Stadler Date: 2012-04-20 15:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e7f3f0541429 Merge From tiark.rompf at epfl.ch Wed Apr 25 09:14:47 2012 From: tiark.rompf at epfl.ch (Tiark Rompf) Date: Wed, 25 Apr 2012 18:14:47 +0200 Subject: Snippets and programmatically creating new classes Message-ID: <18B66BDD-284B-4C93-ABF9-F890998DEF14@epfl.ch> Hi all, I've been playing with Graal a little since you guys came visiting EPFL in March. I like the idea of Snippets and I was wondering, what is the preferred way of adding and deploying custom Snippets that are specific to a particular application or library? Also, is there a suggested way of programmatically creating new classes or methods? For example, I would like to implement something similar to java.lang.reflect.Proxy.newProxyInstance, creating an object on the fly that implements a bunch of interfaces, where the method bodies are created directly using Graal IR. Is there an API for this or would I still need to produce some byte code and pass it through a class loader? Cheers, - Tiark From thomas.wuerthinger at oracle.com Thu Apr 26 01:55:40 2012 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 26 Apr 2012 01:55:40 -0700 Subject: Snippets and programmatically creating new classes In-Reply-To: <18B66BDD-284B-4C93-ABF9-F890998DEF14@epfl.ch> References: <18B66BDD-284B-4C93-ABF9-F890998DEF14@epfl.ch> Message-ID: <4F990D8C.6000008@oracle.com> Tiark, the currently available way for an application or library to actively register snippets is to call the Snippets.install(...) method. There are three parameters: - A reference to the runtime where the snippet definition should replace existing method definitions. - A reference to the description of the target architecture. - An instance of the class that contains the snippet definitions. You can retrieve pointers to the former two by calling CompilerImpl.getGraalRuntime() and CompilerImpl.getInstance().getTarget(). We do not (yet) have a way to create an interface implementation by only using Graal IR. The closest you can get to this is by using the "RiCompiledMethod" class that allows you to directly call installed machine code. In combination with an InvocationHandler implementation you can create an interface proxy without generating bytecodes. Calls to installed methods are restricted to three object parameters. We are working on relaxing that restriction. - thomas On 25.04.2012 09:14, Tiark Rompf wrote: > Hi all, > > I've been playing with Graal a little since you guys came visiting EPFL in March. > I like the idea of Snippets and I was wondering, what is the preferred way of adding and > deploying custom Snippets that are specific to a particular application or library? > > Also, is there a suggested way of programmatically creating new classes or methods? > For example, I would like to implement something similar to > java.lang.reflect.Proxy.newProxyInstance, creating an object on the fly that > implements a bunch of interfaces, where the method bodies are created directly using > Graal IR. Is there an API for this or would I still need to produce some byte code > and pass it through a class loader? > > Cheers, > - Tiark From thomas.wuerthinger at oracle.com Thu Apr 26 02:00:08 2012 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 26 Apr 2012 02:00:08 -0700 Subject: Graal - first step In-Reply-To: <201204041133.q34BX2ij030797@monge.univ-mlv.fr> References: <201204041133.q34BX2ij030797@monge.univ-mlv.fr> Message-ID: <4F990E98.7050802@oracle.com> Yes. Thanks for outlining the use case. In that case we would use a side data structure to encode the information. There are utility functions in the Graph class to create such side data structures: Graph.createNodeBitMap and Graph.createNodeMap. We use those to keep the number of fields in the node classes as small as possible. - thomas On 04.04.2012 04:33, Remi Forax wrote: > The decision to profile or not should not be a global decision. > > Let's take an example, delayed de-visualization. > Language like scalable or java8 allows to write high order functions > that by example loop over a collection of items and call a block of > code for each element. > From a VM point of view the call to the block of code is megamorphic. > One way to devirtualize it is to let the interpreter to profile the > code so we will have enough information to find which concrete high > order function is called thus be able to inline it but instead of > generating only a vtable call for the block call one can also add a > code that will profile the type again. > Because the code was inclined, the block call is not megamorphic > anymore and a second generation will be able to fully online the high > order function call at callsite. > So deciding to insert profiling information should not be done globally. > > R?mi > > Sent from my Phone > > ----- Reply message ----- > From: "Thomas Wuerthinger" > To: "R?mi Forax" > Cc: > Subject: Graal - first step > Date: Wed, Apr 4, 2012 11:23 > > > On 04.04.2012 00:16, R?mi Forax wrote: > >>> Another related problem is that there is currently no node that does > >>> profiling so > >>> I can't generate a graph of nodes with profile information that I > >>> will be able to extract > >>> using Graal interface with Hotspot. > >> It is possible to generate a node that will lower itself to a > >> store/load to an object that is pointing to the profiling data. The > >> Graal snippet mechanism would allow to specify the lowering in Java > >> code (like we do with arraycopy intrinsification, see > >> ArrayCopySnippets class). What kind of general-purpose interface > >> would you suggest for weaving profiling code into the Graal IR? > > > > I think some nodes like IfNode, SwitchNode, InstanceOfNode etc. should > > have a boolean > > asking for generating the record code, in order to record branch taken, > > type profile and exception seen. > > By example for IfNode, a boolean profileBranchTakenProbability will ask > > the code generator to generate the record code for each branch of > the if. > > > > and as you said, a new phase should be introduced that will add new > > Nodes (using snippet) > > to generate the record code where it should be generated. > We could add a phase that automatically inserts such code on every > control split. What is the format / Java data structure in which you > would like to have it recorded? > > - thomas From jim.duey at gmail.com Thu Apr 26 13:39:50 2012 From: jim.duey at gmail.com (Jim Duey) Date: Thu, 26 Apr 2012 15:39:50 -0500 Subject: Question about exceptions Message-ID: <4F99B296.9080008@gmail.com> Hi all, I'm reading through BciBlockMapping.java and I came across this: private void addExceptionEdges() { for (int bci = canTrap.nextSetBit(0); bci >= 0; bci = canTrap.nextSetBit(bci + 1)) { Block block = blockMap[bci]; ArrayList handlers = null; for (RiExceptionHandler h : this.exceptionHandlers) { if (h.startBCI() <= bci && bci < h.endBCI()) { if (handlers == null) { handlers = new ArrayList<>(); } handlers.add(h); if (h.isCatchAll()) { break; } } } if (handlers != null) { Block dispatch = makeExceptionDispatch(handlers, 0, bci); block.successors.add(dispatch); } } } The inner loop builds an array of exception handlers, but the call to only seems to make a dispatch for the first element of the array. Is that intended? Should dispatches be made for each handler in the array? Is there some ordering to the exceptionHandlers list that makes this moot? Thanks, Jim From jim.duey at gmail.com Thu Apr 26 13:46:58 2012 From: jim.duey at gmail.com (Jim Duey) Date: Thu, 26 Apr 2012 15:46:58 -0500 Subject: Question about exceptions Message-ID: <4F99B442.502@gmail.com> Nevermind. I missed the recursive call to makeExceptionDispatch. From thomas.wuerthinger at oracle.com Thu Apr 26 14:28:50 2012 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Thu, 26 Apr 2012 14:28:50 -0700 Subject: Question about exceptions In-Reply-To: <4F99B442.502@gmail.com> References: <4F99B442.502@gmail.com> Message-ID: <4F99BE12.3040308@oracle.com> The Graal compiler adds the logic for dispatching an exception based on its type into the compiled code. The makeExceptionDispatch method creates a subgraph that contains this logic for a list of exception handlers. In order to reduce code size, we only compile exception handlers that have been executed at least once. - thomas