From thomas.wuerthinger at oracle.com Wed May 1 09:22:12 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 1 May 2013 18:22:12 +0200 Subject: access to JIRA bug tracking lists for Graal In-Reply-To: <32A3FBD0-648C-4E9B-8B21-1CBE14A8CA56@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A732A2C66A@sausexdag06.amd.com> <32A3FBD0-648C-4E9B-8B21-1CBE14A8CA56@oracle.com> Message-ID: <9EFF2295-A218-45B9-A08F-48A05889FDC2@oracle.com> Yes, there should not be references to inaccessible URLs in the commit messages. - thomas On Apr 29, 2013, at 8:25 PM, Christian Thalinger wrote: > > On Apr 29, 2013, at 8:29 AM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> Whom should we contact to get access to the JIRA bug tracking lists for Graal development? >> >> >> For example, we want to be able to access https://lafo.ssw.uni-linz.ac.at/jira/browse/GRAAL-234 > > I don't think there is any useful information in that bug. This is probably only a tracking bug. > > Partly this is my fault because I started to file GRAAL issues to track my work and I used them in my reviews. Maybe we should stop it. > > -- Chris > >> >> Vasanth > From thomas.wuerthinger at oracle.com Wed May 1 09:24:38 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 1 May 2013 18:24:38 +0200 Subject: RFR(M) GRAAL-234 - PTX code loader In-Reply-To: <517E8751.3070901@oracle.com> References: <517E8751.3070901@oracle.com> Message-ID: <8FDC6D1D-512E-452B-BEE7-F75BA8B86741@oracle.com> Thanks for the patch! This looks great. - thomas On Apr 29, 2013, at 4:44 PM, Morris Meyer wrote: > Folks, > > I have extended the Graal PTX back-end to incorporate a light and tight linkage to Nvidia GPUs. I've managed to have the Graal-generated PTX code from Java methods properly compile using the Cuda 5.0 drivers on my GTX 660 graphics card. > > If you are wondering about this comment in src/share/vm/runtime/thread.cpp: > > // Initialize the os module before using TLS > os::init(); > > + // probe for warp capability > + gpu::init(); > + > > Per http://docs.nvidia.com/cuda/pdf/ptx_isa_3.1.pdf - the Parallel Thread Execution ISA Version 3.1 from Nvidia: > > "A warp is a maximal subset of threads from a single cooperative thread array (CTA), such that the threads execute the same instructions at the same time. ...Each grid of CTAs has a 1D, 2D or 3D shape" > > I am currently assigned JDK-8013168, which is to extend the set of code pointers from Method to support multiple architectures. This will be necessary to adapt the loaded GPU kernel to internal HotSpot method invocation, as well as architectures that have a heterogeneous CPU+APU configuration. > > WEBREV - http://cr.openjdk.java.net/~morris/GRAAL-234.01 > JIRA - https://lafo.ssw.uni-linz.ac.at/jira/browse/GRAAL-234 > > --morris > > "to boldly go" > > __________________________________________________________________ > > Output: > > vendor: 0x000010DE > device: 0x000011C0 > model: NVIDIA GeForce GTX 660 > gpu_bsd::probe_gpu(APPLE): 1 > gpu::Ptx::probe_linkage > gpu_ptx::probe_linkage(APPLE): 1 > gpu::initialize_gpu > gpu_ptx::_cuda_cu_init: 0 > gpu_ptx::_cuda_cu_device_get_count(1): 0 > gpu_ptx::_cuda_cu_device_get(0): 0 > gpu_ptx::_cuda_cu_device_compute_capability(major 3, minor 0): 0 > gpu_ptx::_cuda_cu_device_get_name(GeForce GTX 660): 0 > gpu_ptx::_cuda_cu_ctx_create(3b013800): 0 > gpu_ptx::initialize_gpu(): 1 > gpu::generate_kernel > gpu::Ptx::generate_kernel > gpu_ptx::_cuda_cu_module_load_data_ex(39b575a0): 0 > gpu_ptx::jit_log_buffer > > gpu_ptx::_cuda_cu_module_get_function(testAddConst1I):3b119600 0 > testAddConst1I: > .version 1.4 > .target sm_10 > .entry testAddConst1I ( > .param .u32 param0 > ) { > .reg .pred %p,%q; > .reg .u32 %r<16>; > L121: > add.s32 %r2, %r2, 1; > mov.s32 %r0, %r2; > exit; > } From Vasanth.Venkatachalam at amd.com Thu May 2 15:15:50 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 2 May 2013 22:15:50 +0000 Subject: mx vm server option Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8B7457@sausexdag06.amd.com> Hi, One of our test cases works when run without the -vm server option but fails when run with this option. The code generated when this option is enabled is different and we don't yet understand why. Are there any changes triggered by this option which could account for these differences? Also have there been any recently introduced changes which affect what this option does? Our test case used to work with and without this option before we merged with the latest trunk. Vasanth From doug.simon at oracle.com Fri May 3 03:15:21 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 3 May 2013 12:15:21 +0200 Subject: mx vm server option In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8B7457@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8B7457@sausexdag06.amd.com> Message-ID: <42B5A5D2-205E-428C-9177-B9FA3124D634@oracle.com> Hi Vasanth, On May 3, 2013, at 12:15 AM, "Venkatachalam, Vasanth" wrote: > Hi, > > One of our test cases works when run without the -vm server option but fails when run with this option. > > The code generated when this option is enabled is different and we don't yet understand why. Could you please provide more detail on how your test case fails and what is different about the generated code. > Are there any changes triggered by this option which could account for these differences? Not that I'm aware of. > Also have there been any recently introduced changes which affect what this option does? Our test case used to work with and without this option before we merged with the latest trunk. I pushed one change yesterday that fixed an issue with Catch_StackOverflowError_01. It triggered when C2 compiled code threw an exception that unwound to Graal compiled code. The (new) exception handler stub in Graal asserts that the exception PC stored in the current thread is 0 and this assertion was failing. -Doug From Vasanth.Venkatachalam at amd.com Fri May 3 09:23:46 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 3 May 2013 16:23:46 +0000 Subject: tool or option for viewing LIR nodes Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8B8E47@sausexdag06.amd.com> Is there a tool or option that would allow us to view the LIR nodes that Graal generates for a program? We're debugging the code generated for one of our test cases and would find it useful to visualize the nodes so that we can see if they makes sense and whether the code we're generating is aligned with those nodes. Vasanth From christian.wimmer at oracle.com Fri May 3 10:21:43 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Fri, 03 May 2013 10:21:43 -0700 Subject: tool or option for viewing LIR nodes In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8B8E47@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8B8E47@sausexdag06.amd.com> Message-ID: <5183F227.8030207@oracle.com> On 05/03/2013 09:23 AM, Venkatachalam, Vasanth wrote: > Is there a tool or option that would allow us to view the LIR nodes that Graal generates for a program? Yes. Graal can output the graph, LIR, register allocator liveness information, and machine code in the format required by the Client Compiler Visualizer. As the name implies, the tool was originally written to visualize the data structures of the Java HotSpot client compiler. You can get it here: https://java.net/projects/c1visualizer/ The output is controlled the same ways as the output to the Ideal Graph Visualizer, i.e., the -G:Dump= flag. In addition, I think you have to also pass -G:+PrintCFG The tool is file-based, i.e., you get .cfg files in your working directory that you can load with the c1visualizer. -Christian From tom.deneau at amd.com Fri May 3 14:34:47 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 3 May 2013 21:34:47 +0000 Subject: junit test question Message-ID: As you know, some AMD folks are working on an graal HSAIL backend and when the HSAIL spec becomes public we want to push this out to the public graal repository. We have some HSAIL Junit tests which dispatch thru HSA and compare to Java results and so will only work on a target that supports HSAIL (either in hardware or thru a simulator). Are these kinds of tests OK to put in graal? That is, do graal users expect to be able to run all the junit tests in all the projects (using the global 'mx unittest' or do they typically only run the tests from selected projects. Or is there a way to indicate that tests in certain projects should not be run by default when someone enters the global "mx unittest" (similar to the way we don't build certain projects unless say jdk8 is being used). -- Tom From thomas.wuerthinger at oracle.com Fri May 3 15:23:08 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Sat, 4 May 2013 00:23:08 +0200 Subject: junit test question In-Reply-To: References: Message-ID: <2E86D54F-DCA7-4B14-9E3B-F7E0DC527E78@oracle.com> Can you use the Assume functionality of JUnit [1]? If possible, we would like to keep the "mx unittest" harness simple - but we can definitely adjust it if necessary. - thomas [1] http://junit.sourceforge.net/javadoc/org/junit/Assume.html On May 3, 2013, at 11:34 PM, "Deneau, Tom" wrote: > As you know, some AMD folks are working on an graal HSAIL backend and > when the HSAIL spec becomes public we want to push this out to the > public graal repository. > > We have some HSAIL Junit tests which dispatch thru HSA and compare to > Java results and so will only work on a target that supports HSAIL > (either in hardware or thru a simulator). > > Are these kinds of tests OK to put in graal? That is, do graal users > expect to be able to run all the junit tests in all the projects (using > the global 'mx unittest' or do they typically only run the tests from > selected projects. > > Or is there a way to indicate that tests in certain projects should > not be run by default when someone enters the global "mx unittest" (similar to > the way we don't build certain projects unless say jdk8 is being > used). > > -- Tom > > From tom.deneau at amd.com Fri May 3 16:01:48 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 3 May 2013 23:01:48 +0000 Subject: junit test question In-Reply-To: <2E86D54F-DCA7-4B14-9E3B-F7E0DC527E78@oracle.com> References: <2E86D54F-DCA7-4B14-9E3B-F7E0DC527E78@oracle.com> Message-ID: Will look into this but this looks like it will help. -- Tom From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Friday, May 03, 2013 5:23 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: junit test question Can you use the Assume functionality of JUnit [1]? If possible, we would like to keep the "mx unittest" harness simple - but we can definitely adjust it if necessary. - thomas [1] http://junit.sourceforge.net/javadoc/org/junit/Assume.html On May 3, 2013, at 11:34 PM, "Deneau, Tom" > wrote: As you know, some AMD folks are working on an graal HSAIL backend and when the HSAIL spec becomes public we want to push this out to the public graal repository. We have some HSAIL Junit tests which dispatch thru HSA and compare to Java results and so will only work on a target that supports HSAIL (either in hardware or thru a simulator). Are these kinds of tests OK to put in graal? That is, do graal users expect to be able to run all the junit tests in all the projects (using the global 'mx unittest' or do they typically only run the tests from selected projects. Or is there a way to indicate that tests in certain projects should not be run by default when someone enters the global "mx unittest" (similar to the way we don't build certain projects unless say jdk8 is being used). -- Tom From Vasanth.Venkatachalam at amd.com Fri May 3 17:30:58 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Sat, 4 May 2013 00:30:58 +0000 Subject: tool or option for viewing LIR nodes Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8B9041@sausexdag06.amd.com> Christian, Some more context to my question. I've added a Graal backend for HSAIL code generation. I'm debugging the codegen for a test case where running with the --vm server option produces some incorrect results. Thus I'd like to view the nodes that are produced when running with the mx --vm server option. It looks like the c1visualizer tool can't be used with --vm server. Is there another tool that can help? I had a similar issue with the IdealGraphVisualizer. The -G:Dump= option isn't recognized when running with --vm server. Vasanth -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer Sent: Friday, May 03, 2013 12:22 PM To: graal-dev at openjdk.java.net Subject: Re: tool or option for viewing LIR nodes On 05/03/2013 09:23 AM, Venkatachalam, Vasanth wrote: > Is there a tool or option that would allow us to view the LIR nodes that Graal generates for a program? Yes. Graal can output the graph, LIR, register allocator liveness information, and machine code in the format required by the Client Compiler Visualizer. As the name implies, the tool was originally written to visualize the data structures of the Java HotSpot client compiler. You can get it here: https://java.net/projects/c1visualizer/ The output is controlled the same ways as the output to the Ideal Graph Visualizer, i.e., the -G:Dump= flag. In addition, I think you have to also pass -G:+PrintCFG The tool is file-based, i.e., you get .cfg files in your working directory that you can load with the c1visualizer. -Christian From christian.thalinger at oracle.com Fri May 3 21:55:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 3 May 2013 21:55:09 -0700 Subject: RFR (XXS): remove basicTypes and basicTypeCount Message-ID: <706E6836-F939-4FAE-9B90-FB01C799B08D@oracle.com> [I'm not preparing a webrev for this one because it's trivial.] http://hg.openjdk.java.net/graal/graal/rev/87e8baf5447c removed the usage of basicTypes and basicTypeCount. diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp --- a/src/share/vm/graal/graalCompilerToVM.cpp +++ b/src/share/vm/graal/graalCompilerToVM.cpp @@ -616,9 +633,6 @@ return id; } -BasicType basicTypes[] = { T_BOOLEAN, T_BYTE, T_SHORT, T_CHAR, T_INT, T_FLOAT, T_LONG, T_DOUBLE, T_OBJECT }; -int basicTypeCount = sizeof(basicTypes) / sizeof(BasicType); - C2V_ENTRY(void, initializeConfiguration, (JNIEnv *env, jobject, jobject config)) #define set_boolean(name, value) do { env->SetBooleanField(config, getFieldID(env, config, name, "Z"), value); } while (0) From christian.thalinger at oracle.com Fri May 3 22:50:27 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 3 May 2013 22:50:27 -0700 Subject: move logic from C++ to Java, Part 1 In-Reply-To: <8DBB6CD8-9CC7-4C8B-9FE8-68F31F5CE845@jku.at> References: <8DBB6CD8-9CC7-4C8B-9FE8-68F31F5CE845@jku.at> Message-ID: <6A01B5D1-0BE7-4040-A7BC-07C85E894ADE@oracle.com> On Feb 11, 2013, at 8:38 AM, Lukas Stadler wrote: > Thanks Christian! I will integrate the patch. Keep them coming :-) > You're right, the more of our logic we have in Java the better. He! This patch never got integrated! ;-) http://hg.openjdk.java.net/graal/graal/rev/674a8b9e62f8 took care of vmPageSize but I still propose the change for windowsOs. I'll send a RFR in a second. -- Chris > > - Lukas > > On Feb 10, 2013, at 5:23 AM, Christian Thalinger wrote: > >> I think we should try to move more code from C++ to Java. This whole Java-native dance makes things just complicated. Here is a small patch to start. >> >> -- Chris >> >> >> graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java src/share/vm/graal/graalCompilerToVM.cpp >> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >> @@ -22,18 +22,21 @@ >> */ >> package com.oracle.graal.hotspot; >> >> +import sun.misc.Unsafe; >> + >> /** >> * Used to communicate configuration details, runtime offsets, etc. to Graal upon compileMethod. >> */ >> public final class HotSpotVMConfig extends CompilerObject { >> >> private static final long serialVersionUID = -4744897993263044184L; >> + private static final Unsafe unsafe = Unsafe.getUnsafe(); >> >> HotSpotVMConfig() { >> } >> >> // os information, register layout, code generation, ... >> - public boolean windowsOs; >> + public final boolean windowsOs = System.getProperty("os.name").startsWith("Windows"); >> public int codeEntryAlignment; >> public boolean verifyOops; >> public boolean ciTime; >> @@ -44,7 +47,7 @@ >> public boolean useAESIntrinsics; >> >> // offsets, ... >> - public int vmPageSize; >> + public final int vmPageSize = unsafe.pageSize(); >> public int stackShadowPages; >> >> /** >> diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp >> --- a/src/share/vm/graal/graalCompilerToVM.cpp >> +++ b/src/share/vm/graal/graalCompilerToVM.cpp >> @@ -602,11 +602,7 @@ >> #define set_int_array(name, value) do { env->SetObjectField(config, getFieldID(env, config, name, "[I"), value); } while (0) >> >> guarantee(HeapWordSize == sizeof(char*), "Graal assumption that HeadWordSize == machine word size is wrong"); >> -#ifdef _WIN64 >> - set_boolean("windowsOs", true); >> -#else >> - set_boolean("windowsOs", false); >> -#endif >> + >> set_boolean("verifyOops", VerifyOops); >> set_boolean("ciTime", CITime); >> set_boolean("useFastLocking", GraalUseFastLocking); >> @@ -615,7 +611,6 @@ >> set_boolean("useAESIntrinsics", UseAESIntrinsics); >> set_boolean("useTLAB", UseTLAB); >> set_int("codeEntryAlignment", CodeEntryAlignment); >> - set_int("vmPageSize", os::vm_page_size()); >> set_int("stackShadowPages", StackShadowPages); >> set_int("hubOffset", oopDesc::klass_offset_in_bytes()); >> set_int("markOffset", oopDesc::mark_offset_in_bytes()); >> > From christian.thalinger at oracle.com Fri May 3 22:50:39 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 3 May 2013 22:50:39 -0700 Subject: RFR (XS): use os.name property to identify Windows OS Message-ID: <2E78778B-683A-40D7-9BEE-64047089A716@oracle.com> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java @@ -34,7 +34,7 @@ // os information, register layout, code generation, ... public boolean cAssertions; - public boolean windowsOs; + public final boolean windowsOs = System.getProperty("os.name", "").startsWith("Windows"); public int codeEntryAlignment; public boolean verifyOops; public boolean ciTime; diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp --- a/src/share/vm/graal/graalCompilerToVM.cpp +++ b/src/share/vm/graal/graalCompilerToVM.cpp @@ -629,11 +643,7 @@ #define set_int_array(name, value) do { env->SetObjectField(config, getFieldID(env, config, name, "[I"), value); } while (0) guarantee(HeapWordSize == sizeof(char*), "Graal assumption that HeadWordSize == machine word size is wrong"); -#ifdef _WIN64 - set_boolean("windowsOs", true); -#else - set_boolean("windowsOs", false); -#endif + set_boolean("cAssertions", DEBUG_ONLY(true) NOT_DEBUG(false)); set_boolean("verifyOops", VerifyOops); set_boolean("ciTime", CITime); From duboscq at ssw.jku.at Sat May 4 13:02:22 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Sat, 4 May 2013 22:02:22 +0200 Subject: tool or option for viewing LIR nodes In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8B9041@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8B9041@sausexdag06.amd.com> Message-ID: The server vm that contains Graal (--vm server) should definitely pick up all -G options including -G:Dump= and -G:+PrintCFG. Since you are talking about unit tests i suppose you are using the GraalCompilerTest's method to explicitly trigger compilation. I don't know how you are structuring your tests but there are some "Debug scopes" that need to be properly set up for these flags to work. Normally if you just make your test a subclass of GraalCompilerTest and then use its methods if should be fine. On Sat, May 4, 2013 at 2:30 AM, Vasanth Venkatachalam < Vasanth.Venkatachalam at amd.com> wrote: > Christian, > > Some more context to my question. > > I've added a Graal backend for HSAIL code generation. I'm debugging the > codegen for a test case where running with the --vm server option produces > some incorrect results. > Thus I'd like to view the nodes that are produced when running with the mx > --vm server option. > > It looks like the c1visualizer tool can't be used with --vm server. Is > there another tool that can help? > > I had a similar issue with the IdealGraphVisualizer. The -G:Dump= option > isn't recognized when running with --vm server. > > Vasanth > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto: > graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer > Sent: Friday, May 03, 2013 12:22 PM > To: graal-dev at openjdk.java.net > Subject: Re: tool or option for viewing LIR nodes > > > On 05/03/2013 09:23 AM, Venkatachalam, Vasanth wrote: > > Is there a tool or option that would allow us to view the LIR nodes that > Graal generates for a program? > > Yes. > > Graal can output the graph, LIR, register allocator liveness information, > and machine code in the format required by the Client Compiler Visualizer. > As the name implies, the tool was originally written to visualize the data > structures of the Java HotSpot client compiler. > > You can get it here: https://java.net/projects/c1visualizer/ > > The output is controlled the same ways as the output to the Ideal Graph > Visualizer, i.e., the -G:Dump= flag. In addition, I think you have to also > pass -G:+PrintCFG > > The tool is file-based, i.e., you get .cfg files in your working directory > that you can load with the c1visualizer. > > -Christian > > > From doug.simon at oracle.com Sat May 4 14:42:31 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 4 May 2013 23:42:31 +0200 Subject: RFR (XXS): remove basicTypes and basicTypeCount In-Reply-To: <706E6836-F939-4FAE-9B90-FB01C799B08D@oracle.com> References: <706E6836-F939-4FAE-9B90-FB01C799B08D@oracle.com> Message-ID: <7FEA1036-524D-42BF-8221-B1453AB86098@oracle.com> Looks fine to me. I wonder how much other dead code there is in the Graal C++ layer? It must all go! On May 4, 2013, at 6:55 AM, Christian Thalinger wrote: > [I'm not preparing a webrev for this one because it's trivial.] > > http://hg.openjdk.java.net/graal/graal/rev/87e8baf5447c removed the usage of basicTypes and basicTypeCount. > > diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp > --- a/src/share/vm/graal/graalCompilerToVM.cpp > +++ b/src/share/vm/graal/graalCompilerToVM.cpp > @@ -616,9 +633,6 @@ > return id; > } > > -BasicType basicTypes[] = { T_BOOLEAN, T_BYTE, T_SHORT, T_CHAR, T_INT, T_FLOAT, T_LONG, T_DOUBLE, T_OBJECT }; > -int basicTypeCount = sizeof(basicTypes) / sizeof(BasicType); > - > C2V_ENTRY(void, initializeConfiguration, (JNIEnv *env, jobject, jobject config)) > > #define set_boolean(name, value) do { env->SetBooleanField(config, getFieldID(env, config, name, "Z"), value); } while (0) > From doug.simon at oracle.com Sat May 4 14:44:32 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 4 May 2013 23:44:32 +0200 Subject: RFR (XS): use os.name property to identify Windows OS In-Reply-To: <2E78778B-683A-40D7-9BEE-64047089A716@oracle.com> References: <2E78778B-683A-40D7-9BEE-64047089A716@oracle.com> Message-ID: Does that also work under cygwin? I know python returns something different. On May 4, 2013, at 7:50 AM, Christian Thalinger wrote: > diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java > --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java > +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java > @@ -34,7 +34,7 @@ > > // os information, register layout, code generation, ... > public boolean cAssertions; > - public boolean windowsOs; > + public final boolean windowsOs = System.getProperty("os.name", "").startsWith("Windows"); > public int codeEntryAlignment; > public boolean verifyOops; > public boolean ciTime; > diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp > --- a/src/share/vm/graal/graalCompilerToVM.cpp > +++ b/src/share/vm/graal/graalCompilerToVM.cpp > @@ -629,11 +643,7 @@ > #define set_int_array(name, value) do { env->SetObjectField(config, getFieldID(env, config, name, "[I"), value); } while (0) > > guarantee(HeapWordSize == sizeof(char*), "Graal assumption that HeadWordSize == machine word size is wrong"); > -#ifdef _WIN64 > - set_boolean("windowsOs", true); > -#else > - set_boolean("windowsOs", false); > -#endif > + > set_boolean("cAssertions", DEBUG_ONLY(true) NOT_DEBUG(false)); > set_boolean("verifyOops", VerifyOops); > set_boolean("ciTime", CITime); > From doug.simon at oracle.com Sat May 4 14:46:54 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 4 May 2013 23:46:54 +0200 Subject: tool or option for viewing LIR nodes In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8B9041@sausexdag06.amd.com> Message-ID: As Gilles says, the -G options should work under --vm server. It helps if you post the complete command line you are using to see if we can spot a problem. -Doug On May 4, 2013, at 10:02 PM, Gilles Duboscq wrote: > The server vm that contains Graal (--vm server) should definitely pick up > all -G options including -G:Dump= and -G:+PrintCFG. > Since you are talking about unit tests i suppose you are using the > GraalCompilerTest's method to explicitly trigger compilation. > > I don't know how you are structuring your tests but there are some "Debug > scopes" that need to be properly set up for these flags to work. Normally > if you just make your test a subclass of GraalCompilerTest and then use its > methods if should be fine. > > > On Sat, May 4, 2013 at 2:30 AM, Vasanth Venkatachalam < > Vasanth.Venkatachalam at amd.com> wrote: > >> Christian, >> >> Some more context to my question. >> >> I've added a Graal backend for HSAIL code generation. I'm debugging the >> codegen for a test case where running with the --vm server option produces >> some incorrect results. >> Thus I'd like to view the nodes that are produced when running with the mx >> --vm server option. >> >> It looks like the c1visualizer tool can't be used with --vm server. Is >> there another tool that can help? >> >> I had a similar issue with the IdealGraphVisualizer. The -G:Dump= option >> isn't recognized when running with --vm server. >> >> Vasanth >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net [mailto: >> graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer >> Sent: Friday, May 03, 2013 12:22 PM >> To: graal-dev at openjdk.java.net >> Subject: Re: tool or option for viewing LIR nodes >> >> >> On 05/03/2013 09:23 AM, Venkatachalam, Vasanth wrote: >>> Is there a tool or option that would allow us to view the LIR nodes that >> Graal generates for a program? >> >> Yes. >> >> Graal can output the graph, LIR, register allocator liveness information, >> and machine code in the format required by the Client Compiler Visualizer. >> As the name implies, the tool was originally written to visualize the data >> structures of the Java HotSpot client compiler. >> >> You can get it here: https://java.net/projects/c1visualizer/ >> >> The output is controlled the same ways as the output to the Ideal Graph >> Visualizer, i.e., the -G:Dump= flag. In addition, I think you have to also >> pass -G:+PrintCFG >> >> The tool is file-based, i.e., you get .cfg files in your working directory >> that you can load with the c1visualizer. >> >> -Christian >> >> >> From doug.simon at oracle.com Sat May 4 18:00:15 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 05 May 2013 01:00:15 +0000 Subject: hg: graal/graal: 177 new changesets Message-ID: <20130505010919.96AE548818@hg.openjdk.java.net> Changeset: addc2a25d727 Author: Thomas Wuerthinger Date: 2013-04-28 06:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/addc2a25d727 Implement merging of frame states if they differ at a merge that does not have its own frame state. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java Changeset: b59b10ddc797 Author: Thomas Wuerthinger Date: 2013-04-28 06:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b59b10ddc797 Do not combine merge with succeeding merge if it holds a stateAfter and the succeeding merge does not. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java Changeset: 6a050090dff8 Author: Thomas Wuerthinger Date: 2013-04-28 06:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6a050090dff8 Preserve begin nodes with associated state. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java Changeset: 86584f07f852 Author: Thomas Wuerthinger Date: 2013-04-28 07:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/86584f07f852 Fix for removeIntermediateMaterialization. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 033b0cd7d342 Author: Thomas Wuerthinger Date: 2013-04-28 07:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/033b0cd7d342 Disable removeIntermediateMaterialization. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 4a9fd6d90284 Author: Thomas Wuerthinger Date: 2013-04-28 08:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4a9fd6d90284 Implement alternative fix for removeIntermediateMaterialization. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: da8823658fe0 Author: Thomas Wuerthinger Date: 2013-04-28 08:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/da8823658fe0 Back out two changes around frame states. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java Changeset: 1152c17b51dc Author: Thomas Wuerthinger Date: 2013-04-28 14:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1152c17b51dc Disable megamorphic inlining. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 708aea0e5a25 Author: Thomas Wuerthinger Date: 2013-04-28 18:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/708aea0e5a25 Introduce proxy nodes for propagating profiling information. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaTypeProfile.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: c8be66a66fcf Author: Thomas Wuerthinger Date: 2013-04-28 18:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c8be66a66fcf Fix left-over debug output. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: afc859750f41 Author: Thomas Wuerthinger Date: 2013-04-28 18:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/afc859750f41 Added missing file. + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java Changeset: 5a74cbafe5b9 Author: Thomas Wuerthinger Date: 2013-04-28 19:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5a74cbafe5b9 Adjustment to the megamorphic inlining strategy such that it focuses on concrete methods. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 6a2a9eac243a Author: Thomas Wuerthinger Date: 2013-04-28 22:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6a2a9eac243a Correctly adjust probabilities when swapping if nodes. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 31dc304507e9 Author: Christos Kotselidis Date: 2013-04-24 21:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/31dc304507e9 New write barrier verification phase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: b11c3539a1e9 Author: Christos Kotselidis Date: 2013-04-24 21:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b11c3539a1e9 Add write barrier verification phase test + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java Changeset: b50583ca9567 Author: Christos Kotselidis Date: 2013-04-25 11:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b50583ca9567 Tread loop begins as safepoints during the verification phase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: 05b8bfa40086 Author: Christos Kotselidis Date: 2013-04-25 11:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/05b8bfa40086 Add more write barrier verification tests ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java Changeset: 9a30199f7ff6 Author: Christos Kotselidis Date: 2013-04-25 12:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9a30199f7ff6 Add comments to write barrier verification tests ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java Changeset: 25c2e9b29e97 Author: Christos Kotselidis Date: 2013-04-25 12:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/25c2e9b29e97 Add comments to write barrier verification phase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: 84ffc957dae3 Author: Christos Kotselidis Date: 2013-04-25 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/84ffc957dae3 Remove blank lines from write barrier verification tests ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java Changeset: 95447e46ac86 Author: Christos Kotselidis Date: 2013-04-25 17:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/95447e46ac86 Simplify write barrier elimination phase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: 8c21cec0301b Author: Christos Kotselidis Date: 2013-04-28 19:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c21cec0301b Remove duplicate write list ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: ca4d71edadcd Author: Christos Kotselidis Date: 2013-04-28 19:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ca4d71edadcd Change input parameter type ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: 365ca8db15a0 Author: Christos Kotselidis Date: 2013-04-28 19:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/365ca8db15a0 Add comments in safepoint detection of WriteBarrierVerification Phase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: 5618a717b8ad Author: Christos Kotselidis Date: 2013-04-28 20:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5618a717b8ad Add comments into WriteBarrierVerificationTest ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java Changeset: a0f72fa35d8b Author: Christos Kotselidis Date: 2013-04-28 21:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a0f72fa35d8b Remove blank line ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java Changeset: 9591dc4a62fa Author: Christos Kotselidis Date: 2013-04-28 21:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9591dc4a62fa Replace dequeue with NodeFlood in WriteBarrierVerification phase ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: c21b1e5b515c Author: Christos Kotselidis Date: 2013-04-28 22:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c21b1e5b515c Small refactoring ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: 16a10b48e526 Author: Christos Kotselidis Date: 2013-04-28 22:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/16a10b48e526 Merge - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/AllocatableValue.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArraySlowStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceSlowStubCall.java - graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Reflection_getCallerClass01.java Changeset: 3270cbd45e03 Author: Christos Kotselidis Date: 2013-04-28 22:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3270cbd45e03 Remove unused import ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java Changeset: 0a94f51ed31b Author: Christos Kotselidis Date: 2013-04-28 23:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a94f51ed31b Merge Changeset: 0097d456ed57 Author: Doug Simon Date: 2013-04-29 10:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0097d456ed57 avoid abbreviation in parameter names ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RegisterPreservationOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RestoreRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java Changeset: 4f8b7dc2766d Author: Bernhard Urban Date: 2013-04-29 12:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f8b7dc2766d SchedulePhase: compute post-dominators in CFG-graph post-dominators are needed by LoweringPhase ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: a58860b72b1f Author: Doug Simon Date: 2013-04-29 18:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a58860b72b1f made AMD64HotSpotRegisterConfig return copies of internal arrays to prevent clients from modifying them ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java Changeset: 016523a011b7 Author: Doug Simon Date: 2013-04-29 18:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/016523a011b7 simplified register preservation in compiled stubs to avoid the need for using ParametersOp ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java - graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RegisterPreservationOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RestoreRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java Changeset: 16c354398d09 Author: twisti Date: 2013-04-29 11:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/16c354398d09 intrinsify Reflection.getCallerClass ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ReflectionGetCallerClassNode.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ReflectionSubstitutions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: ffa27c3058e9 Author: Doug Simon Date: 2013-04-29 21:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ffa27c3058e9 minor simplifications for writing compiled stubs + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CRuntimeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 8d3a7fb9eb5f Author: Doug Simon Date: 2013-04-29 22:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8d3a7fb9eb5f moved binding of parameter locations to runtime call descriptors from platform specific code to shared code for stubs that are now compiled stubs ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: 640d86a6bf4a Author: Doug Simon Date: 2013-04-29 22:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/640d86a6bf4a replaced register_finalizer assembler stub with a compiled stub (GRAAL-81) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RegisterFinalizerStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 393d62a868da Author: Doug Simon Date: 2013-04-30 00:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/393d62a868da replaced thread_is_interrupted assembler stub with a compiled stub (GRAAL-81) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 20dc10bb82d1 Author: Doug Simon Date: 2013-04-30 00:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/20dc10bb82d1 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 149fe42411df Author: Roland Schatz Date: 2013-04-30 12:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/149fe42411df Use platform specific kind in backend. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RegisterValue.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/StackSlot.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/TargetDescription.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/VirtualObject.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/AllocatableValue.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Kind.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/PlatformKind.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Value.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64AddressValue.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXAddressValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/Variable.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java Changeset: 3426008293e7 Author: Roland Schatz Date: 2013-04-30 12:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3426008293e7 Move getSizeInBytes method to Architecture class. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Architecture.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/TargetDescription.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java Changeset: 45e1ea931e9c Author: Roland Schatz Date: 2013-04-30 12:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45e1ea931e9c Remove unused method in MacroAssembler. ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64MacroAssembler.java Changeset: 3ec29630cfb4 Author: Roland Schatz Date: 2013-04-30 12:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3ec29630cfb4 Use register categories instead of register flags. ! graal/com.oracle.graal.amd64/src/com/oracle/graal/amd64/AMD64.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Architecture.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RegisterConfig.java ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64MacroAssembler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64.test/src/com/oracle/graal/hotspot/amd64/test/AMD64HotSpotFrameOmissionTest.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotEpilogueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/Variable.java ! graal/com.oracle.graal.ptx/src/com/oracle/graal/ptx/PTX.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java Changeset: 0f8683ac4009 Author: Roland Schatz Date: 2013-04-30 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0f8683ac4009 Use register categories to determine spill slot size. ! graal/com.oracle.graal.amd64/src/com/oracle/graal/amd64/AMD64.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CalleeSaveLayout.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.ptx/src/com/oracle/graal/ptx/PTX.java Changeset: 334b014a70a3 Author: Roland Schatz Date: 2013-04-30 12:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/334b014a70a3 Don't return vector sizes that the backend doesn't support yet. ! graal/com.oracle.graal.amd64/src/com/oracle/graal/amd64/AMD64.java Changeset: ed9b5a1bea52 Author: Roland Schatz Date: 2013-04-30 12:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ed9b5a1bea52 Separate Architecture creation from TargetDescription. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntime.java Changeset: aaf8798b0969 Author: Roland Schatz Date: 2013-04-30 13:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aaf8798b0969 Load custom runtime implementations. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntimeFactory.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 147162b27799 Author: Morris Meyer Date: 2013-04-30 08:17 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/147162b27799 GRAAL-234 - PTX code loading ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/BasicPTXTest.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java + graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPU.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToGPUImpl.java ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/vm.make ! mx/projects + src/gpu/ptx/gpu_ptx.cpp + src/gpu/ptx/gpu_ptx.hpp + src/os/bsd/vm/gpu_bsd.cpp + src/os/bsd/vm/gpu_bsd.hpp ! src/share/vm/graal/graalCompiler.cpp + src/share/vm/graal/graalCompilerToGPU.cpp + src/share/vm/graal/graalCompilerToGPU.hpp ! src/share/vm/runtime/globals.hpp + src/share/vm/runtime/gpu.cpp + src/share/vm/runtime/gpu.hpp ! src/share/vm/runtime/thread.cpp Changeset: c0488f573091 Author: Roland Schatz Date: 2013-04-30 19:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c0488f573091 Make AMD64 LIR generator extensible. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java Changeset: 6680389bd36f Author: Roland Schatz Date: 2013-04-30 19:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6680389bd36f Make assembler creation in backend more extensible. ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java Changeset: 45a73cd19baa Author: Roland Schatz Date: 2013-04-30 19:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/45a73cd19baa Use the correct move instruction for register saving and restoring. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RestoreRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java Changeset: 50f02c7d1cec Author: Thomas Wuerthinger Date: 2013-04-28 23:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/50f02c7d1cec Rename EndNode => AbstractEndNode and make abstract class. Introduce concrete EndNode subclass. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/SimpleCFGTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariables.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractEndNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/EndNode.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/LoopEndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/MergeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/ComputeImmediateDominator.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeadCodeEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/EliminatePartiallyRedundantGuardsPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeInliningRelevanceClosure.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/PostOrderNodeIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantBlockIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ScopedPostOrderNodeIterator.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/IdealGraphPrinter.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java Changeset: 794370a64b71 Author: Thomas Wuerthinger Date: 2013-04-29 00:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/794370a64b71 Replace AbstractEndNode usages with EndNode usages wherever appropriate. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/PostOrderNodeIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ScopedPostOrderNodeIterator.java Changeset: ae815a4c112a Author: Thomas Wuerthinger Date: 2013-04-29 00:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae815a4c112a Rename BeginNode => AbstractBeginNode and make abstract. Introduce concrete subclass BeginNode. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/SimpleCFGTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.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.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopPolicies.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopTransformLowPhase.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginStateSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ControlSplitNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/EndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/EntryMarkerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ProxyNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/Block.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IntegerSwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConvertDeoptimizeToGuardPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/CullFrameStatesPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/EliminatePartiallyRedundantGuardsPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeInliningRelevanceClosure.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/MergeableState.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/PostOrderNodeIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinter.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/IdealGraphPrinter.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetFrameStateCleanupPhase.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 7c23515c3e82 Author: Thomas Wuerthinger Date: 2013-04-29 00:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7c23515c3e82 Add missing file. + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java Changeset: 3e884486cc8a Author: Gilles Duboscq Date: 2013-04-30 19:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e884486cc8a Fix non-static args binding in JTT Do not run the version with arg binding when there is no args ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/JTTTest.java Changeset: 8fbd481f3d75 Author: Gilles Duboscq Date: 2013-04-30 19:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8fbd481f3d75 Ignore profile probability for gotos in graphbuilder ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: e35cf6b23b34 Author: Gilles Duboscq Date: 2013-04-30 19:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e35cf6b23b34 Add the condition that was negated in Negatable.negate ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Negatable.java Changeset: ee3279c0f9a0 Author: Gilles Duboscq Date: 2013-04-30 19:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ee3279c0f9a0 Merge ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractEndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/EndNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 46e83862cc03 Author: Gilles Duboscq Date: 2013-04-30 19:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/46e83862cc03 Fix merge ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java < graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractEndNode.java < graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/EndNode.java Changeset: 490d283dbe90 Author: Gilles Duboscq Date: 2013-04-30 19:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/490d283dbe90 Add Logic conjunction and disjunction and expand them before lir generation ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicBinaryNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicConjunctionNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicDisjunctionNode.java + graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ExpandLogicPhase.java Changeset: fd60b73f1759 Author: Gilles Duboscq Date: 2013-04-30 19:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fd60b73f1759 Add LoopLimitCheck deoptimization reason ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DeoptimizationReason.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 18906f4dfe77 Author: Gilles Duboscq Date: 2013-04-30 19:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/18906f4dfe77 Add autogrow possibility to NodeMap enable it for the nodeToBlock map of the ControlFlowGraph ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeMap.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: 27733a62ba72 Author: Gilles Duboscq Date: 2013-04-30 20:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/27733a62ba72 Fixes and improvements for induction variables ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/BasicInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/CountedLoopInfo.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedOffsetInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/DerivedScaledInductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/InductionVariable.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopsData.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java Changeset: 6160dc257c79 Author: Gilles Duboscq Date: 2013-04-30 20:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6160dc257c79 Remove useless code in LoopEndNode.canSafepoint ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopEndNode.java Changeset: 7b88c5e5cbd4 Author: Gilles Duboscq Date: 2013-04-30 20:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7b88c5e5cbd4 Add more canonicalizations for Compare and Negate nodes ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/CompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NegateNode.java Changeset: 3d309a26d4d5 Author: Gilles Duboscq Date: 2013-04-30 21:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d309a26d4d5 Add canonicalization to interger div ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IntegerDivNode.java Changeset: ca34e36c53e8 Author: Gilles Duboscq Date: 2013-04-30 21:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ca34e36c53e8 Add loop safepoint elimination ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/CountedLoopInfo.java + graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopSafepointEliminationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/OptimisticOptimizations.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/LowTierContext.java Changeset: 3ccda80d466b Author: Doug Simon Date: 2013-04-30 19:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3ccda80d466b stack overflow check and deopt/exception handler entry points are omitted from compiled stubs ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java Changeset: c1ba734c1ea0 Author: Doug Simon Date: 2013-04-30 19:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c1ba734c1ea0 more extensive checking of compiled stub invariants ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: cdc839f22a23 Author: Doug Simon Date: 2013-04-30 20:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cdc839f22a23 renamed HotSpot specific parts of deoptimization stub: DEOPTIMIZE -> UNCOMMON_TRAP ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 85a836bcd796 Author: Doug Simon Date: 2013-04-30 20:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/85a836bcd796 renaming for improved clarity: hasCall -> destroysCallerSavedRegisters ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RuntimeCallTarget.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/RegisterVerifier.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Call.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRVerifier.java Changeset: 62af2ee39bc5 Author: Doug Simon Date: 2013-04-30 20:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/62af2ee39bc5 moved initialization of UNCOMMON_TRAP descriptor from AMD64 code to platform independent code ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 21ccdce289b2 Author: Doug Simon Date: 2013-04-30 20:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/21ccdce289b2 moved declaration of EXCEPTION_HANDLER, DEOPT_HANDLER and IC_MISS_HANDLER descriptors to platform independent code ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 3e7d22d31f7e Author: Doug Simon Date: 2013-04-30 20:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e7d22d31f7e replaced stub_printf assembler stub with a compiled stub (GRAAL-81) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 75eb896f053a Author: Doug Simon Date: 2013-04-30 20:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/75eb896f053a documented the descriptors for certain HotSpot runtime stubs ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java Changeset: c021bfc839e6 Author: Doug Simon Date: 2013-04-30 20:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c021bfc839e6 Merge. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java Changeset: 56c12e0c15c1 Author: Doug Simon Date: 2013-04-30 22:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56c12e0c15c1 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: a14fef4fca7d Author: Doug Simon Date: 2013-04-30 00:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a14fef4fca7d replaced identity_hash_code assembler stub with a compiled stub (GRAAL-81) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/IdentityHashCodeStubCall.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/IdentityHashCodeStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 861a9e0aba38 Author: Doug Simon Date: 2013-04-30 23:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/861a9e0aba38 Merge. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 902a974d55c8 Author: Doug Simon Date: 2013-04-30 23:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/902a974d55c8 Merge. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/IdentityHashCodeStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: b5d83338286f Author: Thomas Wuerthinger Date: 2013-05-01 15:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b5d83338286f Fix post dominator calculation. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: 89c5c388d6d5 Author: Thomas Wuerthinger Date: 2013-05-01 15:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/89c5c388d6d5 Fix for assertion. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: b8cae7920bca Author: Thomas Wuerthinger Date: 2013-05-01 15:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b8cae7920bca Fix postorder calculation. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: 3531cdfddff6 Author: Thomas Wuerthinger Date: 2013-05-01 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3531cdfddff6 Ensure probabilities are never negative. Add additional assertions. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/NodesToDoubles.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: d80d5e8e29ef Author: Thomas Wuerthinger Date: 2013-05-01 16:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d80d5e8e29ef Remove dead code. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: 8c37649cbb62 Author: Thomas Wuerthinger Date: 2013-05-01 17:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8c37649cbb62 Fixes for probability calculation. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 225fc5463430 Author: Thomas Wuerthinger Date: 2013-05-01 17:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/225fc5463430 Make sure if trueSuccessor probability is always <= 1.0. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 5fa54bf57f8c Author: Doug Simon Date: 2013-05-01 17:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5fa54bf57f8c replaced exception_handler_nofpu assembler stub with a compiled stub (GRAAL-81) generalized stub printf mechanism to also serve as a fatal VM exit message ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCRuntimeCallEpilogueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCRuntimeCallPrologueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotPatchReturnAddressOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/PatchReturnAddressNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotSnippetUtils.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/CompiledExceptionHandlerTest.java + graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/DeoptimizeOnExceptionTest.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: e4e2686f30df Author: Doug Simon Date: 2013-05-01 18:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e4e2686f30df Merge. Changeset: 5c258c1feb82 Author: Christian Wimmer Date: 2013-05-01 09:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5c258c1feb82 Add JavaType-to-String that produces same result as Class.getName() ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java Changeset: 85f83b7b3616 Author: Christian Wimmer Date: 2013-05-01 09:09 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/85f83b7b3616 Fix parameter type of NodeIntrinsic ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java Changeset: 6f84aacfdf3c Author: Christian Wimmer Date: 2013-05-01 09:11 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/6f84aacfdf3c Infer stamp for LoadIndexedNode, so that we have more precise type information for the result of the array load. This is important when the array is a originally a phi function (whithout any type information) and the phi function gets eliminated later on. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadIndexedNode.java Changeset: deb3189e834d Author: Christian Wimmer Date: 2013-05-01 09:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/deb3189e834d Inline method in snippet when replacement is available. Replacements are frequently used for native methods, which are per default excluded from inlining. But if there is a non-native replacement, we want it inlined. ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java Changeset: 3b02fe9e1983 Author: Christian Wimmer Date: 2013-05-01 09:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3b02fe9e1983 Bugfix: loop transformation needs the Assumptions object since it internally calls the Canonicalizer ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: fb22b4d5f475 Author: Christian Wimmer Date: 2013-05-01 09:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fb22b4d5f475 Allow distinction between ClassCastException and ArrayStoreException. Add more canonicalizations for check casts. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastDynamicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/CheckCastTest.java Changeset: fd2e12d41d18 Author: Christian Wimmer Date: 2013-05-01 09:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fd2e12d41d18 Merge ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: d9fd6af5d200 Author: Christian Wimmer Date: 2013-05-01 10:01 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/d9fd6af5d200 Merge ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 1964cf13c376 Author: Christian Wimmer Date: 2013-05-01 11:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/1964cf13c376 Relax the type requirements for CheckCastDynamicNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastDynamicNode.java Changeset: 37345671860c Author: Christian Wimmer Date: 2013-05-01 11:29 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/37345671860c Better handling of array access nodes in Word type rewriter ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: e577da5a49f2 Author: Christian Wimmer Date: 2013-05-01 12:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e577da5a49f2 Pass Assumptions to CanonicalizerPhase to avoid NullPointerException ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java Changeset: 2b663d5893d3 Author: Christian Wimmer Date: 2013-05-01 13:33 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/2b663d5893d3 Allow rounding errors in probabilities ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java Changeset: 62838eadbf56 Author: Andreas Woess Date: 2013-05-01 23:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/62838eadbf56 Windows build fix for PTX code ! make/windows/makefiles/projectcreator.make ! src/gpu/ptx/gpu_ptx.cpp Changeset: 6678695afc3b Author: Andreas Woess Date: 2013-05-01 19:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6678695afc3b NodeUtil.cloneNode: cloned children array should preserve component type. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 0285fbb8b05d Author: Andreas Woess Date: 2013-05-01 23:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0285fbb8b05d NodeUtil.findFirstNodeInstance bug fix ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 01a85ad09b5e Author: Christian Wimmer Date: 2013-05-01 18:06 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/01a85ad09b5e Add generic type to avoid Java compiler warnings ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RuntimeCallTarget.java Changeset: b9e66fc67b31 Author: Christian Wimmer Date: 2013-05-01 18:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/b9e66fc67b31 Use MetaAccessProvider instead of CodeCacheProvider ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java Changeset: 3822ce079ec4 Author: Christian Wimmer Date: 2013-05-01 18:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/3822ce079ec4 Merge Changeset: 789cfd153265 Author: Doug Simon Date: 2013-05-02 06:08 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/789cfd153265 a compiled stub can now specify whether it needs to preserve registers. If a stub does not preserve registers and assertions are enabled, then all non-temporary registers are zapped after a C runtime call from the stub. the ExceptionHandler stub no longer preserves registers ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java + graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RegistersPreservationOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java + graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ZapRegistersOp.java Changeset: c5bdf71cb5d7 Author: Bernhard Urban Date: 2013-05-02 10:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c5bdf71cb5d7 nested checkcasts: add failing testcase by Christian Wimmer ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java Changeset: 38b07e59dcbb Author: Bernhard Urban Date: 2013-05-02 10:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/38b07e59dcbb CheckCastNode: better attempt to combine checkcasts ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java Changeset: 82b2a2c652bb Author: Bernhard Urban Date: 2013-05-02 10:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/82b2a2c652bb CheckCastNode: check if input of next CheckCastNode is the node itself ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java Changeset: 6ad0bdcd76aa Author: Lukas Stadler Date: 2013-04-25 17:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6ad0bdcd76aa make Node.getDebugProperties() final ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java Changeset: 13978836b7e2 Author: Lukas Stadler Date: 2013-04-25 17:10 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/13978836b7e2 don't verify ControlFlowGraph when connectBlocks == false ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: 394f1232d563 Author: Lukas Stadler Date: 2013-04-25 17:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/394f1232d563 late lowering of allocations (NewInstanceNode, NewArrayNode, NewMultiArrayNode) ! 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/java/NewMultiArrayNode.java Changeset: d0b3fa50e306 Author: Lukas Stadler Date: 2013-04-30 13:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d0b3fa50e306 lower FixedGuardNode to if-condition-deopt in after-guard lowering ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java Changeset: e37aca5c2062 Author: Lukas Stadler Date: 2013-04-29 10:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e37aca5c2062 only virtualize StoreIndexedNode if no store check is required ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreIndexedNode.java Changeset: 9cc37ce426cc Author: Lukas Stadler Date: 2013-04-29 18:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9cc37ce426cc factor out createFieldLocation in HotSpotRuntime ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: bef43373de39 Author: Lukas Stadler Date: 2013-04-29 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bef43373de39 coalesce allocations during escape analysis ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/EscapeAnalysisTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ea/PartialEscapeAnalysisTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/DebugInfoBuilder.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/AllocatedObjectNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualBoxingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualObjectNode.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/MaterializeObjectNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java Changeset: 6b19d1000809 Author: Lukas Stadler Date: 2013-04-30 12:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b19d1000809 remove debug code ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: f364c77077ff Author: Lukas Stadler Date: 2013-04-30 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f364c77077ff handle "~" in EscapeAnalyzeOnly ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java Changeset: 106f0a0acafa Author: Lukas Stadler Date: 2013-04-30 17:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/106f0a0acafa refactored monitor handling in EA: MonitorEnter/Exit is removed, not eliminated ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/BeginLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CurrentLockNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/InitializeArrayNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/InitializeObjectNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/BoxNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessMonitorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorEnterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.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/Virtualizable.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/VirtualizerTool.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualBoxingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualObjectNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/ObjectState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: d48b7a4b93e9 Author: Roland Schatz Date: 2013-05-02 11:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d48b7a4b93e9 Backed out changeset: 45a73cd19baa ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RestoreRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java Changeset: 6703dca691d7 Author: Roland Schatz Date: 2013-05-02 14:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6703dca691d7 Restructure register zapping. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ZapRegistersOp.java Changeset: 3df71c132731 Author: Roland Schatz Date: 2013-05-02 14:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3df71c132731 Make register saving extensible. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RestoreRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java Changeset: 2b7857aaa1c0 Author: Roland Schatz Date: 2013-05-02 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2b7857aaa1c0 Merge. - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/MaterializeObjectNode.java Changeset: 688219709f7b Author: Roland Schatz Date: 2013-05-02 16:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/688219709f7b Remove StackSlot and RegisterValue cache. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/StackSlot.java Changeset: 3fdbe6a68103 Author: Roland Schatz Date: 2013-05-02 16:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3fdbe6a68103 Pass fixed node into getMaterializedRepresentation. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualBoxingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualInstanceNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualObjectNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java Changeset: 715f82d1f695 Author: Gilles Duboscq Date: 2013-05-02 14:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/715f82d1f695 Enable the loop safepoint elimination. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopSafepointEliminationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/LowTierContext.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/MidTierContext.java Changeset: 05b8a812b487 Author: Gilles Duboscq Date: 2013-05-02 14:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/05b8a812b487 Remove dead IsNull nodes in Guard lowering phase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: 659bb6cf930c Author: Doug Simon Date: 2013-05-02 11:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/659bb6cf930c rename: HotSpotSnippetUtils -> HotSpotReplacementsUtil ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotInstalledCodeExecuteNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ClassSubstitutions.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotSnippetUtils.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ThreadSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/TypeCheckSnippetUtils.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/WriteBarrierSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/IdentityHashCodeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RegisterFinalizerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java Changeset: 56dc7fe83f8a Author: Doug Simon Date: 2013-05-02 11:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/56dc7fe83f8a rename: VERY_FAST_DEOPT_PATH_PROBABILITY -> VERY_FAST_PATH_PROBABILITY ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/BranchProbabilityNode.java Changeset: 9384ec90632b Author: Doug Simon Date: 2013-05-02 12:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9384ec90632b Merge. Changeset: cf8104ed68ba Author: Doug Simon Date: 2013-05-02 14:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cf8104ed68ba Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/MaterializeObjectNode.java Changeset: 51973e9ec004 Author: Doug Simon Date: 2013-05-02 15:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51973e9ec004 added comments clarifying the difference between _exception_oop and _pending_exception in the HotSpot Thread class ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java Changeset: f491f51e96b5 Author: Doug Simon Date: 2013-05-02 17:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f491f51e96b5 exception PC stored in thread is cleared before entering ExceptionHandlerStub ! src/share/vm/runtime/sharedRuntime.cpp Changeset: af0b79174c3d Author: Doug Simon Date: 2013-05-02 17:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/af0b79174c3d exposed whether ASSERT is defined to Java code and use it to enable checks in ExceptionHandlerStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 3bb1834202f7 Author: Doug Simon Date: 2013-05-02 17:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3bb1834202f7 Merge. Changeset: 79dab3bce7d0 Author: Andreas Woess Date: 2013-05-02 18:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/79dab3bce7d0 FrameDescriptor: fix default frame slot kind. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/FrameDescriptor.java Changeset: f63750de9dc9 Author: Andreas Woess Date: 2013-05-02 01:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f63750de9dc9 Preliminary Nashorn support in IGV. ! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/CustomFilter.java Changeset: bd8cb5779a4e Author: Christian Wimmer Date: 2013-05-02 10:26 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bd8cb5779a4e Rename field to be consistent with name of accessor method ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AccessIndexedNode.java Changeset: ff8d87eabda8 Author: Christian Wimmer Date: 2013-05-02 10:36 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ff8d87eabda8 Refactor the LocationNode class hierarchy to allow a SnippetLocationNode, i.e., a LocationNode that can be used in snippets without requiring the individual components to be constants at the time the snippet is prepared ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ConstantLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LocationNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SnippetLocationNode.java Changeset: 038fa65cbd8d Author: Christian Wimmer Date: 2013-05-02 10:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/038fa65cbd8d Consistent naming of accessor methods in the LocationNode class hierarchy ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ConstantLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SnippetLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java Changeset: ae5cd887e67c Author: Christian Wimmer Date: 2013-05-02 12:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ae5cd887e67c Use a LocationIdentity interface instead of just Object for the location identity of a LocationNode ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/BeginLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DirectCompareAndSwapNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/EndLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotInstalledCodeExecuteNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/TypeCheckSnippetUtils.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StartNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AddLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ConstantLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IndexedLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MembarNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MemoryCheckpoint.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SnippetLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteMemoryCheckpointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorEnterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Pointer.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Word.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: f49e1f023f7d Author: Christian Wimmer Date: 2013-05-02 12:13 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f49e1f023f7d Merge Changeset: 2c540cdf4af9 Author: Andreas Woess Date: 2013-05-03 02:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2c540cdf4af9 Fix casts in UnboxNode. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnboxNode.java Changeset: afbb1b5a0eaa Author: Bernhard Urban Date: 2013-05-02 20:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/afbb1b5a0eaa TypeProfileProxy: add missing return ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java Changeset: 2777aafe689b Author: Bernhard Urban Date: 2013-05-02 21:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2777aafe689b TypeProfileProxy: remove profile proxies after inlining logic before, profiles were lost after the first iteration of IterativeInliningPhase (if enabled) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/TypeProfileProxyNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java Changeset: 63b4cea1ed3f Author: Doug Simon Date: 2013-05-03 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/63b4cea1ed3f suppressed output for expected AssertionError in WriteBarrierVerificationTest ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java Changeset: 8f854c4deabf Author: Gilles Duboscq Date: 2013-05-03 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8f854c4deabf Delay lowering of the platform specific OSR entry ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/OnStackReplacementPhase.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractLocalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LocalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/OSRLocalNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/OSRStartNode.java Changeset: 298e47193781 Author: Gilles Duboscq Date: 2013-05-03 15:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/298e47193781 Fix for delayed OSR: we must drop the precise stamps we have on the OSR locals since they may be too precise because of branch pruining in the graph builder. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/OnStackReplacementPhase.java Changeset: 197994e68e43 Author: Gilles Duboscq Date: 2013-05-03 15:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/197994e68e43 float to double conversion is lossless ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConvertNode.java Changeset: cf9b3e717bda Author: Gilles Duboscq Date: 2013-05-03 15:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cf9b3e717bda GraphBuilderPhase.genGoto does not need to provide a probability to createTarget ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 238431ec62a2 Author: Christian Humer Date: 2013-05-03 14:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/238431ec62a2 Fixed bug in casting execute generation when evaluated parameters for both executed methods were not mapped to a child node. ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeCodeGenerator.java Changeset: e2965e5cd474 Author: Christian Humer Date: 2013-05-03 14:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e2965e5cd474 Fixed Truffle child iterator should only iterate children which are annotated with @Child or @Children. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/GraphPrintVisitor.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: e6fe35d64b71 Author: Christian Humer Date: 2013-05-03 15:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e6fe35d64b71 Implemented a method to produce a compact string representation of the truffle tree which just shows the nodes and their children but no data fields. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 05c523b6633b Author: Christian Humer Date: 2013-05-03 15:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/05c523b6633b Merge. Changeset: 438bde0e12ba Author: Christian Humer Date: 2013-05-03 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/438bde0e12ba Merge. Changeset: 4bd247fc3625 Author: Bernhard Urban Date: 2013-05-03 14:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4bd247fc3625 GraalOptions: use detected number of cores by runtime for `Threads' ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 8a6bd04d9510 Author: Bernhard Urban Date: 2013-05-03 15:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a6bd04d9510 CheckCastNode: add test for load field vialoation a field access must be guarded by a cast ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java Changeset: f8a5f7f7d0bd Author: Bernhard Urban Date: 2013-05-03 15:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f8a5f7f7d0bd CheckCastNode: eliminate the other way around and replace the previous node with a more specific node regarding its type ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/EliminateNestedCheckCastsTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java Changeset: 5bf09c5cd2e6 Author: Bernhard Urban Date: 2013-05-03 16:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5bf09c5cd2e6 ReadNode/PiPush: compute declaring class by field offset instead of obtaining it through the LocationIdentity ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/PushNodesThroughPiTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java Changeset: 7931508747f5 Author: Christian Wimmer Date: 2013-05-03 09:24 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/7931508747f5 Fix parameters of node intrinsics to use more specific Location and LocationIdentity types. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SnippetLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java Changeset: 6f51dc49e163 Author: Lukas Stadler Date: 2013-05-03 20:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6f51dc49e163 fix CommitAllocationNode duplication ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java Changeset: 8b126a466917 Author: Lukas Stadler Date: 2013-05-03 20:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8b126a466917 Merge (fixed 106f0a0acafa) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/CommitAllocationNode.java Changeset: 52353ed06cdf Author: Lukas Stadler Date: 2013-05-03 20:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/52353ed06cdf Merge (fixed: 3fdbe6a68103 Pass fixed node into getMaterializedRepresentation.) Changeset: c45c0bda3602 Author: Lukas Stadler Date: 2013-05-03 20:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c45c0bda3602 Merge (fixed: 05b8a812b487 Remove dead IsNull nodes in Guard lowering phase) Changeset: 49b2c7b65e62 Author: Lukas Stadler Date: 2013-05-03 20:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/49b2c7b65e62 Merge (fixed: 3bb1834202f7 Merge) - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotSnippetUtils.java Changeset: 71330feed39d Author: Lukas Stadler Date: 2013-05-03 20:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/71330feed39d Merge (fixed: f63750de9dc9 Preliminary Nashorn support in IGV) Changeset: 6fed251e3cee Author: Lukas Stadler Date: 2013-05-03 20:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6fed251e3cee Merge (fixed: f49e1f023f7d Merge) Changeset: 58a2ff06f4b4 Author: Lukas Stadler Date: 2013-05-03 20:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/58a2ff06f4b4 Merge (fixed: 2777aafe689b TypeProfileProxy: remove profile proxies after inlining logic) Changeset: 8ccca4b4f880 Author: Lukas Stadler Date: 2013-05-03 20:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8ccca4b4f880 Merge (fixed: cf9b3e717bda GraphBuilderPhase.genGoto does not need to provide a probability to createTarget) Changeset: 76937211a12d Author: Lukas Stadler Date: 2013-05-03 20:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/76937211a12d Merge (fixed: 5bf09c5cd2e6 ReadNode/PiPush: compute declaring class by field offset) Changeset: 54748fae40d7 Author: Lukas Stadler Date: 2013-05-03 20:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/54748fae40d7 Merge (fixed: 7931508747f5 Fix parameters of node intrinsics to use more specific Location and LocationIden) Changeset: 9e77e858b6eb Author: Doug Simon Date: 2013-05-04 01:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9e77e858b6eb removed calls to VerifyOop stub from compiled stubs (stubs cannot call stubs) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java From Vasanth.Venkatachalam at amd.com Mon May 6 08:29:55 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 6 May 2013 15:29:55 +0000 Subject: tool or option for viewing LIR nodes In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8B9041@sausexdag06.amd.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8B993E@sausexdag06.amd.com> Doug and Giles, Here's the command line I'm using. tester at see-anna1:~/graalcloneinternal/graal$ ./mx.sh --vm server --java-home /home/tester/graal/jdk1.7.0_13/debug -G:Dump= -G:+PrintCFG unittest BasicHSAILTest ... mx: error: unrecognized arguments: -G:Dump= -G:+PrintCFG Can someone explain what I'm doing wrong here? Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Saturday, May 04, 2013 4:47 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: tool or option for viewing LIR nodes As Gilles says, the -G options should work under --vm server. It helps if you post the complete command line you are using to see if we can spot a problem. -Doug On May 4, 2013, at 10:02 PM, Gilles Duboscq wrote: > The server vm that contains Graal (--vm server) should definitely pick > up all -G options including -G:Dump= and -G:+PrintCFG. > Since you are talking about unit tests i suppose you are using the > GraalCompilerTest's method to explicitly trigger compilation. > > I don't know how you are structuring your tests but there are some > "Debug scopes" that need to be properly set up for these flags to > work. Normally if you just make your test a subclass of > GraalCompilerTest and then use its methods if should be fine. > > > On Sat, May 4, 2013 at 2:30 AM, Vasanth Venkatachalam < > Vasanth.Venkatachalam at amd.com> wrote: > >> Christian, >> >> Some more context to my question. >> >> I've added a Graal backend for HSAIL code generation. I'm debugging >> the codegen for a test case where running with the --vm server option >> produces some incorrect results. >> Thus I'd like to view the nodes that are produced when running with >> the mx --vm server option. >> >> It looks like the c1visualizer tool can't be used with --vm server. >> Is there another tool that can help? >> >> I had a similar issue with the IdealGraphVisualizer. The -G:Dump= >> option isn't recognized when running with --vm server. >> >> Vasanth >> >> -----Original Message----- >> From: graal-dev-bounces at openjdk.java.net [mailto: >> graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer >> Sent: Friday, May 03, 2013 12:22 PM >> To: graal-dev at openjdk.java.net >> Subject: Re: tool or option for viewing LIR nodes >> >> >> On 05/03/2013 09:23 AM, Venkatachalam, Vasanth wrote: >>> Is there a tool or option that would allow us to view the LIR nodes >>> that >> Graal generates for a program? >> >> Yes. >> >> Graal can output the graph, LIR, register allocator liveness >> information, and machine code in the format required by the Client Compiler Visualizer. >> As the name implies, the tool was originally written to visualize the >> data structures of the Java HotSpot client compiler. >> >> You can get it here: https://java.net/projects/c1visualizer/ >> >> The output is controlled the same ways as the output to the Ideal >> Graph Visualizer, i.e., the -G:Dump= flag. In addition, I think you >> have to also pass -G:+PrintCFG >> >> The tool is file-based, i.e., you get .cfg files in your working >> directory that you can load with the c1visualizer. >> >> -Christian >> >> >> From lukas.stadler at jku.at Mon May 6 08:36:59 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Mon, 6 May 2013 17:36:59 +0200 Subject: RFR (XS): use os.name property to identify Windows OS In-Reply-To: References: <2E78778B-683A-40D7-9BEE-64047089A716@oracle.com> Message-ID: Looks good to me, sorry that I never integrated the original patch? This property is set by src/windows/native/java/lang/java_props_md.c on Windows, and all options in there start with "Windows". - Lukas On May 4, 2013, at 11:44 PM, Doug Simon wrote: > Does that also work under cygwin? I know python returns something different. > > On May 4, 2013, at 7:50 AM, Christian Thalinger wrote: > >> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >> @@ -34,7 +34,7 @@ >> >> // os information, register layout, code generation, ... >> public boolean cAssertions; >> - public boolean windowsOs; >> + public final boolean windowsOs = System.getProperty("os.name", "").startsWith("Windows"); >> public int codeEntryAlignment; >> public boolean verifyOops; >> public boolean ciTime; >> diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp >> --- a/src/share/vm/graal/graalCompilerToVM.cpp >> +++ b/src/share/vm/graal/graalCompilerToVM.cpp >> @@ -629,11 +643,7 @@ >> #define set_int_array(name, value) do { env->SetObjectField(config, getFieldID(env, config, name, "[I"), value); } while (0) >> >> guarantee(HeapWordSize == sizeof(char*), "Graal assumption that HeadWordSize == machine word size is wrong"); >> -#ifdef _WIN64 >> - set_boolean("windowsOs", true); >> -#else >> - set_boolean("windowsOs", false); >> -#endif >> + >> set_boolean("cAssertions", DEBUG_ONLY(true) NOT_DEBUG(false)); >> set_boolean("verifyOops", VerifyOops); >> set_boolean("ciTime", CITime); >> > From doug.simon at oracle.com Mon May 6 08:41:14 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 6 May 2013 17:41:14 +0200 Subject: tool or option for viewing LIR nodes In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8B993E@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8B9041@sausexdag06.amd.com> <5DD1503F815BD14889DC81D28643E3A73D8B993E@sausexdag06.amd.com> Message-ID: <3FAFD914-4B74-4DA6-9681-E1942D4BFC7F@oracle.com> On May 6, 2013, at 5:29 PM, "Venkatachalam, Vasanth" wrote: > Doug and Giles, > > Here's the command line I'm using. > > tester at see-anna1:~/graalcloneinternal/graal$ ./mx.sh --vm server --java-home /home/tester/graal/jdk1.7.0_13/debug -G:Dump= -G:+PrintCFG unittest BasicHSAILTest > ... > mx: error: unrecognized arguments: -G:Dump= -G:+PrintCFG > > Can someone explain what I'm doing wrong here? You want: ./mx.sh --vm server --java-home /home/tester/graal/jdk1.7.0_13/debug unittest BasicHSAILTest @-G:Dump= @-G:+PrintCFG That is, the VM options need to come after the 'unit test' command specifier *and* they must be prefixed with '@'. Sorry for the complexity of this command - we are planning on unifying all mx commands to use the same (or at least a more unified) interface. If the method you are particularly interested in is com.amd.Test.myTest(), then you should also add: @-G:MethodFilter=myTest or: @-G:MethodFilter=Test.* to dump traces for all methods in the Test class. -Doug > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Saturday, May 04, 2013 4:47 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: tool or option for viewing LIR nodes > > As Gilles says, the -G options should work under --vm server. It helps if you post the complete command line you are using to see if we can spot a problem. > > -Doug > > On May 4, 2013, at 10:02 PM, Gilles Duboscq wrote: > >> The server vm that contains Graal (--vm server) should definitely pick >> up all -G options including -G:Dump= and -G:+PrintCFG. >> Since you are talking about unit tests i suppose you are using the >> GraalCompilerTest's method to explicitly trigger compilation. >> >> I don't know how you are structuring your tests but there are some >> "Debug scopes" that need to be properly set up for these flags to >> work. Normally if you just make your test a subclass of >> GraalCompilerTest and then use its methods if should be fine. >> >> >> On Sat, May 4, 2013 at 2:30 AM, Vasanth Venkatachalam < >> Vasanth.Venkatachalam at amd.com> wrote: >> >>> Christian, >>> >>> Some more context to my question. >>> >>> I've added a Graal backend for HSAIL code generation. I'm debugging >>> the codegen for a test case where running with the --vm server option >>> produces some incorrect results. >>> Thus I'd like to view the nodes that are produced when running with >>> the mx --vm server option. >>> >>> It looks like the c1visualizer tool can't be used with --vm server. >>> Is there another tool that can help? >>> >>> I had a similar issue with the IdealGraphVisualizer. The -G:Dump= >>> option isn't recognized when running with --vm server. >>> >>> Vasanth >>> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net [mailto: >>> graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer >>> Sent: Friday, May 03, 2013 12:22 PM >>> To: graal-dev at openjdk.java.net >>> Subject: Re: tool or option for viewing LIR nodes >>> >>> >>> On 05/03/2013 09:23 AM, Venkatachalam, Vasanth wrote: >>>> Is there a tool or option that would allow us to view the LIR nodes >>>> that >>> Graal generates for a program? >>> >>> Yes. >>> >>> Graal can output the graph, LIR, register allocator liveness >>> information, and machine code in the format required by the Client Compiler Visualizer. >>> As the name implies, the tool was originally written to visualize the >>> data structures of the Java HotSpot client compiler. >>> >>> You can get it here: https://java.net/projects/c1visualizer/ >>> >>> The output is controlled the same ways as the output to the Ideal >>> Graph Visualizer, i.e., the -G:Dump= flag. In addition, I think you >>> have to also pass -G:+PrintCFG >>> >>> The tool is file-based, i.e., you get .cfg files in your working >>> directory that you can load with the c1visualizer. >>> >>> -Christian >>> >>> >>> > > > From christian.thalinger at oracle.com Mon May 6 09:36:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 May 2013 09:36:09 -0700 Subject: RFR (XS): use os.name property to identify Windows OS In-Reply-To: References: <2E78778B-683A-40D7-9BEE-64047089A716@oracle.com> Message-ID: <0F48EEF4-10BF-4F9E-830B-2E85EA445680@oracle.com> On May 4, 2013, at 2:44 PM, Doug Simon wrote: > Does that also work under cygwin? I know python returns something different. I couldn't find a cygwin yet but MKS says: os.name=Windows 2003 What does Python return? -- Chris > > On May 4, 2013, at 7:50 AM, Christian Thalinger wrote: > >> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >> @@ -34,7 +34,7 @@ >> >> // os information, register layout, code generation, ... >> public boolean cAssertions; >> - public boolean windowsOs; >> + public final boolean windowsOs = System.getProperty("os.name", "").startsWith("Windows"); >> public int codeEntryAlignment; >> public boolean verifyOops; >> public boolean ciTime; >> diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp >> --- a/src/share/vm/graal/graalCompilerToVM.cpp >> +++ b/src/share/vm/graal/graalCompilerToVM.cpp >> @@ -629,11 +643,7 @@ >> #define set_int_array(name, value) do { env->SetObjectField(config, getFieldID(env, config, name, "[I"), value); } while (0) >> >> guarantee(HeapWordSize == sizeof(char*), "Graal assumption that HeadWordSize == machine word size is wrong"); >> -#ifdef _WIN64 >> - set_boolean("windowsOs", true); >> -#else >> - set_boolean("windowsOs", false); >> -#endif >> + >> set_boolean("cAssertions", DEBUG_ONLY(true) NOT_DEBUG(false)); >> set_boolean("verifyOops", VerifyOops); >> set_boolean("ciTime", CITime); >> > From christian.thalinger at oracle.com Mon May 6 09:41:22 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 May 2013 09:41:22 -0700 Subject: RFR (XXS): remove basicTypes and basicTypeCount In-Reply-To: <7FEA1036-524D-42BF-8221-B1453AB86098@oracle.com> References: <706E6836-F939-4FAE-9B90-FB01C799B08D@oracle.com> <7FEA1036-524D-42BF-8221-B1453AB86098@oracle.com> Message-ID: <8944E859-281E-4838-871C-807A84340117@oracle.com> On May 4, 2013, at 2:42 PM, Doug Simon wrote: > Looks fine to me. Thanks. > > I wonder how much other dead code there is in the Graal C++ layer? It must all go! I'll keep my eyes open. There is another clean-up/fix I have; will send out later today. -- Chris > > On May 4, 2013, at 6:55 AM, Christian Thalinger wrote: > >> [I'm not preparing a webrev for this one because it's trivial.] >> >> http://hg.openjdk.java.net/graal/graal/rev/87e8baf5447c removed the usage of basicTypes and basicTypeCount. >> >> diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp >> --- a/src/share/vm/graal/graalCompilerToVM.cpp >> +++ b/src/share/vm/graal/graalCompilerToVM.cpp >> @@ -616,9 +633,6 @@ >> return id; >> } >> >> -BasicType basicTypes[] = { T_BOOLEAN, T_BYTE, T_SHORT, T_CHAR, T_INT, T_FLOAT, T_LONG, T_DOUBLE, T_OBJECT }; >> -int basicTypeCount = sizeof(basicTypes) / sizeof(BasicType); >> - >> C2V_ENTRY(void, initializeConfiguration, (JNIEnv *env, jobject, jobject config)) >> >> #define set_boolean(name, value) do { env->SetBooleanField(config, getFieldID(env, config, name, "Z"), value); } while (0) >> > From doug.simon at oracle.com Mon May 6 10:05:27 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 6 May 2013 19:05:27 +0200 Subject: RFR (XS): use os.name property to identify Windows OS In-Reply-To: <0F48EEF4-10BF-4F9E-830B-2E85EA445680@oracle.com> References: <2E78778B-683A-40D7-9BEE-64047089A716@oracle.com> <0F48EEF4-10BF-4F9E-830B-2E85EA445680@oracle.com> Message-ID: On May 6, 2013, at 6:36 PM, Christian Thalinger wrote: > > On May 4, 2013, at 2:44 PM, Doug Simon wrote: > >> Does that also work under cygwin? I know python returns something different. > > I couldn't find a cygwin yet but MKS says: > > os.name=Windows 2003 > > What does Python return? It depends: http://stackoverflow.com/questions/1387222/reliably-detect-windows-in-python -Doug >> >> On May 4, 2013, at 7:50 AM, Christian Thalinger wrote: >> >>> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >>> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >>> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java >>> @@ -34,7 +34,7 @@ >>> >>> // os information, register layout, code generation, ... >>> public boolean cAssertions; >>> - public boolean windowsOs; >>> + public final boolean windowsOs = System.getProperty("os.name", "").startsWith("Windows"); >>> public int codeEntryAlignment; >>> public boolean verifyOops; >>> public boolean ciTime; >>> diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp >>> --- a/src/share/vm/graal/graalCompilerToVM.cpp >>> +++ b/src/share/vm/graal/graalCompilerToVM.cpp >>> @@ -629,11 +643,7 @@ >>> #define set_int_array(name, value) do { env->SetObjectField(config, getFieldID(env, config, name, "[I"), value); } while (0) >>> >>> guarantee(HeapWordSize == sizeof(char*), "Graal assumption that HeadWordSize == machine word size is wrong"); >>> -#ifdef _WIN64 >>> - set_boolean("windowsOs", true); >>> -#else >>> - set_boolean("windowsOs", false); >>> -#endif >>> + >>> set_boolean("cAssertions", DEBUG_ONLY(true) NOT_DEBUG(false)); >>> set_boolean("verifyOops", VerifyOops); >>> set_boolean("ciTime", CITime); >>> >> > From christian.thalinger at oracle.com Mon May 6 14:24:03 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 May 2013 14:24:03 -0700 Subject: RFR (S): make lookupConstantInPool use ConstantPool logic Message-ID: This change uses the ConstantPool logic to do the lookups. It also implements missing constant pool types like JVM_CONSTANT_MethodHandle and JVM_CONSTANT_MethodType. test.java.lang.invoke.InvokeDynamicPrintArgs can now be run like: $ java -XX:-BootstrapGraal -Xcomp -XX:CompileCommand=compileonly,test.java.lang.invoke.*::* -XX:+PrintCompilation -cp test/java/lang/invoke/:. indify.Indify --java test.java.lang.invoke.InvokeDynamicPrintArgs -- Chris diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp --- a/src/share/vm/graal/graalCompilerToVM.cpp +++ b/src/share/vm/graal/graalCompilerToVM.cpp @@ -391,35 +391,52 @@ oop result = NULL; constantTag tag = cp->tag_at(index); - if (tag.is_int()) { - result = VMToCompiler::createConstant(Kind::Int(), cp->int_at(index), CHECK_0); - } else if (tag.is_long()) { - result = VMToCompiler::createConstant(Kind::Long(), cp->long_at(index), CHECK_0); - } else if (tag.is_float()) { - result = VMToCompiler::createConstantFloat(cp->float_at(index), CHECK_0); - } else if (tag.is_double()) { - result = VMToCompiler::createConstantDouble(cp->double_at(index), CHECK_0); - } else if (tag.is_string()) { - oop string = NULL; - if (cp->is_pseudo_string_at(index)) { - int obj_index = cp->cp_to_object_index(index); - string = cp->pseudo_string_at(index, obj_index); - } else { - string = cp->string_at(index, THREAD); - if (HAS_PENDING_EXCEPTION) { - CLEAR_PENDING_EXCEPTION; - // TODO: Gracefully exit compilation. - fatal("out of memory during compilation!"); - return NULL; - } + + switch (tag.value()) { + case JVM_CONSTANT_Integer: + result = VMToCompiler::createConstant(Kind::Int(), cp->int_at(index), CHECK_NULL); + break; + + case JVM_CONSTANT_Long: + result = VMToCompiler::createConstant(Kind::Long(), cp->long_at(index), CHECK_NULL); + break; + + case JVM_CONSTANT_Float: + result = VMToCompiler::createConstantFloat(cp->float_at(index), CHECK_NULL); + break; + + case JVM_CONSTANT_Double: + result = VMToCompiler::createConstantDouble(cp->double_at(index), CHECK_NULL); + break; + + case JVM_CONSTANT_Class: + case JVM_CONSTANT_UnresolvedClass: + case JVM_CONSTANT_UnresolvedClassInError: + { + Handle type = GraalCompiler::get_JavaType(cp, index, cp->pool_holder(), CHECK_NULL); + result = type(); + break; } - result = VMToCompiler::createConstantObject(string, CHECK_0); - } else if (tag.is_klass() || tag.is_unresolved_klass()) { - Handle type = GraalCompiler::get_JavaType(cp, index, cp->pool_holder(), CHECK_NULL); - result = type(); - } else { - tty->print("unknown constant pool tag (%s) at cpi %d in %s: ", tag.internal_name(), index, cp->pool_holder()->name()->as_C_string()); - ShouldNotReachHere(); + + case JVM_CONSTANT_String: + { + oop result_oop = cp->resolve_possibly_cached_constant_at(index, CHECK_NULL); + result = VMToCompiler::createConstantObject(result_oop, CHECK_NULL); + break; + } + + case JVM_CONSTANT_MethodHandle: + case JVM_CONSTANT_MethodHandleInError: + case JVM_CONSTANT_MethodType: + case JVM_CONSTANT_MethodTypeInError: + { + oop result_oop = cp->resolve_constant_at(index, CHECK_NULL); + result = VMToCompiler::createConstantObject(result_oop, CHECK_NULL); + break; + } + + default: + fatal(err_msg_res("unknown constant pool tag %s at cpi %d in %s", tag.internal_name(), index, cp->pool_holder()->name()->as_C_string())); } return JNIHandles::make_local(THREAD, result); From doug.simon at oracle.com Mon May 6 14:28:31 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 6 May 2013 23:28:31 +0200 Subject: RFR (S): make lookupConstantInPool use ConstantPool logic In-Reply-To: References: Message-ID: <0961E762-5191-4D96-9FC4-61C815634582@oracle.com> Looks good to me. Not sure why we never used tag.value() in the first place - probably just another bit of HotSpot internal API we weren't aware of. -Doug On May 6, 2013, at 11:24 PM, Christian Thalinger wrote: > This change uses the ConstantPool logic to do the lookups. It also implements missing constant pool types like JVM_CONSTANT_MethodHandle and JVM_CONSTANT_MethodType. > > test.java.lang.invoke.InvokeDynamicPrintArgs can now be run like: > > $ java -XX:-BootstrapGraal -Xcomp -XX:CompileCommand=compileonly,test.java.lang.invoke.*::* -XX:+PrintCompilation -cp test/java/lang/invoke/:. indify.Indify --java test.java.lang.invoke.InvokeDynamicPrintArgs > > -- Chris > > diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp > --- a/src/share/vm/graal/graalCompilerToVM.cpp > +++ b/src/share/vm/graal/graalCompilerToVM.cpp > @@ -391,35 +391,52 @@ > > oop result = NULL; > constantTag tag = cp->tag_at(index); > - if (tag.is_int()) { > - result = VMToCompiler::createConstant(Kind::Int(), cp->int_at(index), CHECK_0); > - } else if (tag.is_long()) { > - result = VMToCompiler::createConstant(Kind::Long(), cp->long_at(index), CHECK_0); > - } else if (tag.is_float()) { > - result = VMToCompiler::createConstantFloat(cp->float_at(index), CHECK_0); > - } else if (tag.is_double()) { > - result = VMToCompiler::createConstantDouble(cp->double_at(index), CHECK_0); > - } else if (tag.is_string()) { > - oop string = NULL; > - if (cp->is_pseudo_string_at(index)) { > - int obj_index = cp->cp_to_object_index(index); > - string = cp->pseudo_string_at(index, obj_index); > - } else { > - string = cp->string_at(index, THREAD); > - if (HAS_PENDING_EXCEPTION) { > - CLEAR_PENDING_EXCEPTION; > - // TODO: Gracefully exit compilation. > - fatal("out of memory during compilation!"); > - return NULL; > - } > + > + switch (tag.value()) { > + case JVM_CONSTANT_Integer: > + result = VMToCompiler::createConstant(Kind::Int(), cp->int_at(index), CHECK_NULL); > + break; > + > + case JVM_CONSTANT_Long: > + result = VMToCompiler::createConstant(Kind::Long(), cp->long_at(index), CHECK_NULL); > + break; > + > + case JVM_CONSTANT_Float: > + result = VMToCompiler::createConstantFloat(cp->float_at(index), CHECK_NULL); > + break; > + > + case JVM_CONSTANT_Double: > + result = VMToCompiler::createConstantDouble(cp->double_at(index), CHECK_NULL); > + break; > + > + case JVM_CONSTANT_Class: > + case JVM_CONSTANT_UnresolvedClass: > + case JVM_CONSTANT_UnresolvedClassInError: > + { > + Handle type = GraalCompiler::get_JavaType(cp, index, cp->pool_holder(), CHECK_NULL); > + result = type(); > + break; > } > - result = VMToCompiler::createConstantObject(string, CHECK_0); > - } else if (tag.is_klass() || tag.is_unresolved_klass()) { > - Handle type = GraalCompiler::get_JavaType(cp, index, cp->pool_holder(), CHECK_NULL); > - result = type(); > - } else { > - tty->print("unknown constant pool tag (%s) at cpi %d in %s: ", tag.internal_name(), index, cp->pool_holder()->name()->as_C_string()); > - ShouldNotReachHere(); > + > + case JVM_CONSTANT_String: > + { > + oop result_oop = cp->resolve_possibly_cached_constant_at(index, CHECK_NULL); > + result = VMToCompiler::createConstantObject(result_oop, CHECK_NULL); > + break; > + } > + > + case JVM_CONSTANT_MethodHandle: > + case JVM_CONSTANT_MethodHandleInError: > + case JVM_CONSTANT_MethodType: > + case JVM_CONSTANT_MethodTypeInError: > + { > + oop result_oop = cp->resolve_constant_at(index, CHECK_NULL); > + result = VMToCompiler::createConstantObject(result_oop, CHECK_NULL); > + break; > + } > + > + default: > + fatal(err_msg_res("unknown constant pool tag %s at cpi %d in %s", tag.internal_name(), index, cp->pool_holder()->name()->as_C_string())); > } > > return JNIHandles::make_local(THREAD, result); > From christian.thalinger at oracle.com Mon May 6 14:31:35 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 6 May 2013 14:31:35 -0700 Subject: RFR (S): make lookupConstantInPool use ConstantPool logic In-Reply-To: <0961E762-5191-4D96-9FC4-61C815634582@oracle.com> References: <0961E762-5191-4D96-9FC4-61C815634582@oracle.com> Message-ID: <40757D1C-0CDE-4019-93E0-EC66A4AF3241@oracle.com> On May 6, 2013, at 2:28 PM, Doug Simon wrote: > Looks good to me. > > Not sure why we never used tag.value() in the first place - probably just another bit of HotSpot internal API we weren't aware of. Probably. As I said, I will keep my eyes open and send patches. At least the 292 stuff gets into shape. Thanks for the review. -- Chris > > -Doug > > On May 6, 2013, at 11:24 PM, Christian Thalinger wrote: > >> This change uses the ConstantPool logic to do the lookups. It also implements missing constant pool types like JVM_CONSTANT_MethodHandle and JVM_CONSTANT_MethodType. >> >> test.java.lang.invoke.InvokeDynamicPrintArgs can now be run like: >> >> $ java -XX:-BootstrapGraal -Xcomp -XX:CompileCommand=compileonly,test.java.lang.invoke.*::* -XX:+PrintCompilation -cp test/java/lang/invoke/:. indify.Indify --java test.java.lang.invoke.InvokeDynamicPrintArgs >> >> -- Chris >> >> diff --git a/src/share/vm/graal/graalCompilerToVM.cpp b/src/share/vm/graal/graalCompilerToVM.cpp >> --- a/src/share/vm/graal/graalCompilerToVM.cpp >> +++ b/src/share/vm/graal/graalCompilerToVM.cpp >> @@ -391,35 +391,52 @@ >> >> oop result = NULL; >> constantTag tag = cp->tag_at(index); >> - if (tag.is_int()) { >> - result = VMToCompiler::createConstant(Kind::Int(), cp->int_at(index), CHECK_0); >> - } else if (tag.is_long()) { >> - result = VMToCompiler::createConstant(Kind::Long(), cp->long_at(index), CHECK_0); >> - } else if (tag.is_float()) { >> - result = VMToCompiler::createConstantFloat(cp->float_at(index), CHECK_0); >> - } else if (tag.is_double()) { >> - result = VMToCompiler::createConstantDouble(cp->double_at(index), CHECK_0); >> - } else if (tag.is_string()) { >> - oop string = NULL; >> - if (cp->is_pseudo_string_at(index)) { >> - int obj_index = cp->cp_to_object_index(index); >> - string = cp->pseudo_string_at(index, obj_index); >> - } else { >> - string = cp->string_at(index, THREAD); >> - if (HAS_PENDING_EXCEPTION) { >> - CLEAR_PENDING_EXCEPTION; >> - // TODO: Gracefully exit compilation. >> - fatal("out of memory during compilation!"); >> - return NULL; >> - } >> + >> + switch (tag.value()) { >> + case JVM_CONSTANT_Integer: >> + result = VMToCompiler::createConstant(Kind::Int(), cp->int_at(index), CHECK_NULL); >> + break; >> + >> + case JVM_CONSTANT_Long: >> + result = VMToCompiler::createConstant(Kind::Long(), cp->long_at(index), CHECK_NULL); >> + break; >> + >> + case JVM_CONSTANT_Float: >> + result = VMToCompiler::createConstantFloat(cp->float_at(index), CHECK_NULL); >> + break; >> + >> + case JVM_CONSTANT_Double: >> + result = VMToCompiler::createConstantDouble(cp->double_at(index), CHECK_NULL); >> + break; >> + >> + case JVM_CONSTANT_Class: >> + case JVM_CONSTANT_UnresolvedClass: >> + case JVM_CONSTANT_UnresolvedClassInError: >> + { >> + Handle type = GraalCompiler::get_JavaType(cp, index, cp->pool_holder(), CHECK_NULL); >> + result = type(); >> + break; >> } >> - result = VMToCompiler::createConstantObject(string, CHECK_0); >> - } else if (tag.is_klass() || tag.is_unresolved_klass()) { >> - Handle type = GraalCompiler::get_JavaType(cp, index, cp->pool_holder(), CHECK_NULL); >> - result = type(); >> - } else { >> - tty->print("unknown constant pool tag (%s) at cpi %d in %s: ", tag.internal_name(), index, cp->pool_holder()->name()->as_C_string()); >> - ShouldNotReachHere(); >> + >> + case JVM_CONSTANT_String: >> + { >> + oop result_oop = cp->resolve_possibly_cached_constant_at(index, CHECK_NULL); >> + result = VMToCompiler::createConstantObject(result_oop, CHECK_NULL); >> + break; >> + } >> + >> + case JVM_CONSTANT_MethodHandle: >> + case JVM_CONSTANT_MethodHandleInError: >> + case JVM_CONSTANT_MethodType: >> + case JVM_CONSTANT_MethodTypeInError: >> + { >> + oop result_oop = cp->resolve_constant_at(index, CHECK_NULL); >> + result = VMToCompiler::createConstantObject(result_oop, CHECK_NULL); >> + break; >> + } >> + >> + default: >> + fatal(err_msg_res("unknown constant pool tag %s at cpi %d in %s", tag.internal_name(), index, cp->pool_holder()->name()->as_C_string())); >> } >> >> return JNIHandles::make_local(THREAD, result); >> > From Vasanth.Venkatachalam at amd.com Mon May 6 17:04:48 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 7 May 2013 00:04:48 +0000 Subject: vm server option generating different LIR nodes Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8B9B7B@sausexdag06.amd.com> Hi, I am debugging a test case for my HSAIL backend that is giving the wrong result when run with -vm server option. Using the Client Compiler Visualizer, I noticed that the nodes generated are different with the -vm server option, even before the "After LIR generation" phase. Is there a reason why the nodes would be different when running with -vm server? The nodes shown for the "After linear scan order" phase (right before LIR) look suspicious to me in that it looks like there's a dangling else block, so that the exit out of a loop isn't hitting some cleanup code that needs to be executed. I see this issue propagated down to the LIR, and since my codegen is matching up with the LIR, it inherits the dangling else which seems to be the culprit here. Vasanth From Vasanth.Venkatachalam at amd.com Mon May 6 17:05:48 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 7 May 2013 00:05:48 +0000 Subject: tool or option for viewing LIR nodes In-Reply-To: <3FAFD914-4B74-4DA6-9681-E1942D4BFC7F@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D8B9041@sausexdag06.amd.com> <5DD1503F815BD14889DC81D28643E3A73D8B993E@sausexdag06.amd.com> <3FAFD914-4B74-4DA6-9681-E1942D4BFC7F@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8B9B91@sausexdag06.amd.com> Thanks Doug, that worked. It would be helpful to document this for those of us who are new to the tool. I'm willing to take a stab at this if you like. Vasanth -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Monday, May 06, 2013 10:41 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: tool or option for viewing LIR nodes On May 6, 2013, at 5:29 PM, "Venkatachalam, Vasanth" wrote: > Doug and Giles, > > Here's the command line I'm using. > > tester at see-anna1:~/graalcloneinternal/graal$ ./mx.sh --vm server --java-home /home/tester/graal/jdk1.7.0_13/debug -G:Dump= -G:+PrintCFG unittest BasicHSAILTest > ... > mx: error: unrecognized arguments: -G:Dump= -G:+PrintCFG > > Can someone explain what I'm doing wrong here? You want: ./mx.sh --vm server --java-home /home/tester/graal/jdk1.7.0_13/debug unittest BasicHSAILTest @-G:Dump= @-G:+PrintCFG That is, the VM options need to come after the 'unit test' command specifier *and* they must be prefixed with '@'. Sorry for the complexity of this command - we are planning on unifying all mx commands to use the same (or at least a more unified) interface. If the method you are particularly interested in is com.amd.Test.myTest(), then you should also add: @-G:MethodFilter=myTest or: @-G:MethodFilter=Test.* to dump traces for all methods in the Test class. -Doug > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Saturday, May 04, 2013 4:47 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: tool or option for viewing LIR nodes > > As Gilles says, the -G options should work under --vm server. It helps if you post the complete command line you are using to see if we can spot a problem. > > -Doug > > On May 4, 2013, at 10:02 PM, Gilles Duboscq wrote: > >> The server vm that contains Graal (--vm server) should definitely >> pick up all -G options including -G:Dump= and -G:+PrintCFG. >> Since you are talking about unit tests i suppose you are using the >> GraalCompilerTest's method to explicitly trigger compilation. >> >> I don't know how you are structuring your tests but there are some >> "Debug scopes" that need to be properly set up for these flags to >> work. Normally if you just make your test a subclass of >> GraalCompilerTest and then use its methods if should be fine. >> >> >> On Sat, May 4, 2013 at 2:30 AM, Vasanth Venkatachalam < >> Vasanth.Venkatachalam at amd.com> wrote: >> >>> Christian, >>> >>> Some more context to my question. >>> >>> I've added a Graal backend for HSAIL code generation. I'm debugging >>> the codegen for a test case where running with the --vm server >>> option produces some incorrect results. >>> Thus I'd like to view the nodes that are produced when running with >>> the mx --vm server option. >>> >>> It looks like the c1visualizer tool can't be used with --vm server. >>> Is there another tool that can help? >>> >>> I had a similar issue with the IdealGraphVisualizer. The -G:Dump= >>> option isn't recognized when running with --vm server. >>> >>> Vasanth >>> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net [mailto: >>> graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer >>> Sent: Friday, May 03, 2013 12:22 PM >>> To: graal-dev at openjdk.java.net >>> Subject: Re: tool or option for viewing LIR nodes >>> >>> >>> On 05/03/2013 09:23 AM, Venkatachalam, Vasanth wrote: >>>> Is there a tool or option that would allow us to view the LIR nodes >>>> that >>> Graal generates for a program? >>> >>> Yes. >>> >>> Graal can output the graph, LIR, register allocator liveness >>> information, and machine code in the format required by the Client Compiler Visualizer. >>> As the name implies, the tool was originally written to visualize >>> the data structures of the Java HotSpot client compiler. >>> >>> You can get it here: https://java.net/projects/c1visualizer/ >>> >>> The output is controlled the same ways as the output to the Ideal >>> Graph Visualizer, i.e., the -G:Dump= flag. In addition, I think you >>> have to also pass -G:+PrintCFG >>> >>> The tool is file-based, i.e., you get .cfg files in your working >>> directory that you can load with the c1visualizer. >>> >>> -Christian >>> >>> >>> > > > From doug.simon at oracle.com Tue May 7 02:11:06 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 7 May 2013 11:11:06 +0200 Subject: tool or option for viewing LIR nodes In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8B9B91@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8B9041@sausexdag06.amd.com> <5DD1503F815BD14889DC81D28643E3A73D8B993E@sausexdag06.amd.com> <3FAFD914-4B74-4DA6-9681-E1942D4BFC7F@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D8B9B91@sausexdag06.amd.com> Message-ID: On May 7, 2013, at 2:05 AM, "Venkatachalam, Vasanth" wrote: > Thanks Doug, that worked. It would be helpful to document this for those of us who are new to the tool. > I'm willing to take a stab at this if you like. Sure. Send me some text and I'll add it to the wiki[1]. -Doug [1] https://wiki.openjdk.java.net/display/Graal/Main > > Vasanth > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, May 06, 2013 10:41 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: tool or option for viewing LIR nodes > > > On May 6, 2013, at 5:29 PM, "Venkatachalam, Vasanth" wrote: > >> Doug and Giles, >> >> Here's the command line I'm using. >> >> tester at see-anna1:~/graalcloneinternal/graal$ ./mx.sh --vm server --java-home /home/tester/graal/jdk1.7.0_13/debug -G:Dump= -G:+PrintCFG unittest BasicHSAILTest >> ... >> mx: error: unrecognized arguments: -G:Dump= -G:+PrintCFG >> >> Can someone explain what I'm doing wrong here? > > You want: > > ./mx.sh --vm server --java-home /home/tester/graal/jdk1.7.0_13/debug unittest BasicHSAILTest @-G:Dump= @-G:+PrintCFG > > That is, the VM options need to come after the 'unit test' command specifier *and* they must be prefixed with '@'. Sorry for the complexity of this command - we are planning on unifying all mx commands to use the same (or at least a more unified) interface. > > If the method you are particularly interested in is com.amd.Test.myTest(), then you should also add: > > @-G:MethodFilter=myTest > > or: > > @-G:MethodFilter=Test.* > > to dump traces for all methods in the Test class. > > -Doug > >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Saturday, May 04, 2013 4:47 PM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: tool or option for viewing LIR nodes >> >> As Gilles says, the -G options should work under --vm server. It helps if you post the complete command line you are using to see if we can spot a problem. >> >> -Doug >> >> On May 4, 2013, at 10:02 PM, Gilles Duboscq wrote: >> >>> The server vm that contains Graal (--vm server) should definitely >>> pick up all -G options including -G:Dump= and -G:+PrintCFG. >>> Since you are talking about unit tests i suppose you are using the >>> GraalCompilerTest's method to explicitly trigger compilation. >>> >>> I don't know how you are structuring your tests but there are some >>> "Debug scopes" that need to be properly set up for these flags to >>> work. Normally if you just make your test a subclass of >>> GraalCompilerTest and then use its methods if should be fine. >>> >>> >>> On Sat, May 4, 2013 at 2:30 AM, Vasanth Venkatachalam < >>> Vasanth.Venkatachalam at amd.com> wrote: >>> >>>> Christian, >>>> >>>> Some more context to my question. >>>> >>>> I've added a Graal backend for HSAIL code generation. I'm debugging >>>> the codegen for a test case where running with the --vm server >>>> option produces some incorrect results. >>>> Thus I'd like to view the nodes that are produced when running with >>>> the mx --vm server option. >>>> >>>> It looks like the c1visualizer tool can't be used with --vm server. >>>> Is there another tool that can help? >>>> >>>> I had a similar issue with the IdealGraphVisualizer. The -G:Dump= >>>> option isn't recognized when running with --vm server. >>>> >>>> Vasanth >>>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net [mailto: >>>> graal-dev-bounces at openjdk.java.net] On Behalf Of Christian Wimmer >>>> Sent: Friday, May 03, 2013 12:22 PM >>>> To: graal-dev at openjdk.java.net >>>> Subject: Re: tool or option for viewing LIR nodes >>>> >>>> >>>> On 05/03/2013 09:23 AM, Venkatachalam, Vasanth wrote: >>>>> Is there a tool or option that would allow us to view the LIR nodes >>>>> that >>>> Graal generates for a program? >>>> >>>> Yes. >>>> >>>> Graal can output the graph, LIR, register allocator liveness >>>> information, and machine code in the format required by the Client Compiler Visualizer. >>>> As the name implies, the tool was originally written to visualize >>>> the data structures of the Java HotSpot client compiler. >>>> >>>> You can get it here: https://java.net/projects/c1visualizer/ >>>> >>>> The output is controlled the same ways as the output to the Ideal >>>> Graph Visualizer, i.e., the -G:Dump= flag. In addition, I think you >>>> have to also pass -G:+PrintCFG >>>> >>>> The tool is file-based, i.e., you get .cfg files in your working >>>> directory that you can load with the c1visualizer. >>>> >>>> -Christian >>>> >>>> >>>> >> >> >> > > > From Vasanth.Venkatachalam at amd.com Tue May 7 19:29:23 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 8 May 2013 02:29:23 +0000 Subject: deoptimization nodes Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8BA49D@sausexdag06.amd.com> Hi, When running the test case below with -vm server, Hotspot passes to Graal a Deoptimization Node to handle the case where the while loop of testMandelSimple is exited due to count becoming >=maxIterations. I suspect it's doing this because it thinks this execution path is less frequently taken. The AMD64 backend handles the Deoptimization node by invoking a runtime stub routine, which I suspect is falling back to the interpreter. (Can someone confirm whether this is the case?) For our HSAIL backend, we don't want to handle the deoptimization node in the same way (by fall back to interpreter). Is there a way to prevent Hotspot from generating deoptimization nodes for code paths it thinks are less frequently taken, but to instead force it to generate the complete set of nodes that would normally be generated for these paths? Would running without the -vm server option do the trick? We found when we run without -vm server, the complete set of nodes (for the while loop exit) are generated, and the Deoptimization nodes only get generated by Graal for array bounds checking. This is the behavior we would like to see. Vasanth The following test case can be run in the AMD64 backend. (We ran it in a BasicAMD64Test.java). void setupPalette(int[] in) { for (int i = 0; i < in.length; i++) { in[i] = i; } } @Test public void testMandel() { final int WIDTH = 768; final int HEIGHT = WIDTH; final int maxIterations = 64; int loopiterations = 1; int iter = 0; final int RANGE = WIDTH * HEIGHT; int[] rgb = new int[RANGE]; int[] palette = new int[RANGE];// [maxIterations]; setupPalette(palette); while (iter < loopiterations) { for (int gid = 0; gid < RANGE; gid++) { testMandelSimple(rgb, palette, -1.0f, 0.0f, 3f, gid); } iter++; } test("testMandelSimple"); } public static void testMandelSimple(int rgb[], int pallette[], float x_offset, float y_offset, float scale, int gid) { final int width = 768; final int height = 768; final int maxIterations = 64; float lx = (((gid % width * scale) - ((scale / 2) * width)) / width) + x_offset; float ly = (((gid / width * scale) - ((scale / 2) * height)) / height) + y_offset; int count = 0; float zx = lx; float zy = ly; float new_zx = 0f; // Iterate until the algorithm converges or until maxIterations are reached. while (count < maxIterations && zx * zx + zy * zy < 8) { new_zx = zx * zx - zy * zy + lx; zy = 2 * zx * zy + ly; zx = new_zx; count++; } rgb[gid] = pallette[count]; } From thomas.wuerthinger at oracle.com Wed May 8 22:34:13 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 8 May 2013 22:34:13 -0700 Subject: deoptimization nodes In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8BA49D@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8BA49D@sausexdag06.amd.com> Message-ID: <1D6F8AD6-484F-4D0B-A7F7-926881267CE1@oracle.com> Vasanth, This means that Graal receives profiling feedback that the specific execution path was never taken (during the profiling of the method). You can use the option "-G:-RemoveNeverExecutedCode" to disable the behavior that such paths are replaced with a deoptimization exit. - thomas On May 7, 2013, at 7:29 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > When running the test case below with -vm server, Hotspot passes to Graal a Deoptimization Node to handle the case where the while loop of testMandelSimple is exited due to count becoming >=maxIterations. > > I suspect it's doing this because it thinks this execution path is less frequently taken. The AMD64 backend handles the Deoptimization node by invoking a runtime stub routine, which I suspect is falling back to the interpreter. (Can someone confirm whether this is the case?) > > For our HSAIL backend, we don't want to handle the deoptimization node in the same way (by fall back to interpreter). > > Is there a way to prevent Hotspot from generating deoptimization nodes for code paths it thinks are less frequently taken, but to instead force it to generate the complete set of nodes that would normally be generated for these paths? > > Would running without the -vm server option do the trick? > We found when we run without -vm server, the complete set of nodes (for the while loop exit) are generated, and the Deoptimization nodes only get generated by Graal for array bounds checking. This is the behavior we would like to see. > > Vasanth > > The following test case can be run in the AMD64 backend. (We ran it in a BasicAMD64Test.java). > > void setupPalette(int[] in) { > for (int i = 0; i < in.length; i++) { > in[i] = i; > } > } > > @Test > public void testMandel() { > > final int WIDTH = 768; > final int HEIGHT = WIDTH; > final int maxIterations = 64; > int loopiterations = 1; > int iter = 0; > final int RANGE = WIDTH * HEIGHT; > int[] rgb = new int[RANGE]; > int[] palette = new int[RANGE];// [maxIterations]; > setupPalette(palette); > while (iter < loopiterations) { > for (int gid = 0; gid < RANGE; gid++) { > testMandelSimple(rgb, palette, -1.0f, 0.0f, 3f, gid); > } > iter++; > } > test("testMandelSimple"); > } > > public static void testMandelSimple(int rgb[], int pallette[], float x_offset, float y_offset, float scale, int gid) { > final int width = 768; > final int height = 768; > final int maxIterations = 64; > float lx = (((gid % width * scale) - ((scale / 2) * width)) / width) + x_offset; > float ly = (((gid / width * scale) - ((scale / 2) * height)) / height) + y_offset; > > int count = 0; > float zx = lx; > float zy = ly; > float new_zx = 0f; > > // Iterate until the algorithm converges or until maxIterations are reached. > while (count < maxIterations && zx * zx + zy * zy < 8) { > new_zx = zx * zx - zy * zy + lx; > zy = 2 * zx * zy + ly; > zx = new_zx; > count++; > } > > rgb[gid] = pallette[count]; > > } > From thomas.wuerthinger at oracle.com Wed May 8 22:45:46 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 8 May 2013 22:45:46 -0700 Subject: vm server option generating different LIR nodes In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8B9B7B@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8B9B7B@sausexdag06.amd.com> Message-ID: <9AC7147B-1D4F-49F4-9026-27F448C7988B@oracle.com> Vasanth, the gathered profiling information might be different between the "--vm server" and the "--vm graal" option. In general, linking to the generated "Client Compiler Visualizer" or "IdealGraphVisualizer" files can be very helpful. - thomas On May 6, 2013, at 5:04 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > I am debugging a test case for my HSAIL backend that is giving the wrong result when run with -vm server option. > > Using the Client Compiler Visualizer, I noticed that the nodes generated are different with the -vm server option, even before the "After LIR generation" phase. > > Is there a reason why the nodes would be different when running with -vm server? > > The nodes shown for the "After linear scan order" phase (right before LIR) look suspicious to me in that it looks like there's a dangling else block, so that the exit out of a loop isn't hitting some cleanup code that needs to be executed. I see this issue propagated down to the LIR, and since my codegen is matching up with the LIR, it inherits the dangling else which seems to be the culprit here. > > Vasanth From tom.deneau at amd.com Fri May 10 13:23:19 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 10 May 2013 20:23:19 +0000 Subject: mx unittest with @javaCompliance=1.8 Message-ID: We added a project locally here and marked it with @javaCompliance=1.8 (test cases in this project use lambdas) With that annotation mx build product seems to work fine, it builds that project if the java_home is 1.8, but not 1.7. And if 1.8 is used, we can use mx unittest to run the test cases in that project. However, we had a user who was still using 1.7 and after updating to this new projects file, got the following experience > mx build product # worked fine, did not built the 1.8 project > mx unittest IntSquaredTest # note: IntSquaredTest is in one of the normal 1.7 projects got the error shown below. So it looks like unittest at least is ignoring the fact that this project is 1.8 and looking for its bin directory even though we are using a 1.7 jvm... Traceback (most recent call last): File "/home/tom/graal/mxtool/mx.py", line 3191, in main() File "/home/tom/graal/mxtool/mx.py", line 3180, in main retcode = c(command_args) File "/home/tom/graal/mx/commands.py", line 839, in unittest _unittest(args, ['@Test', '@LongTest']) File "/home/tom/graal/mx/commands.py", line 827, in _unittest _run_tests(args, harness, annotations, testfile) File "/home/tom/graal/mx/commands.py", line 791, in _run_tests classes += _find_classes_with_annotations(p, None, annotations).keys() File "/home/tom/graal/mx/commands.py", line 776, in _find_classes_with_annotations return p.find_classes_with_matching_source_line(pkgRoot, matches, includeInnerClasses) File "/home/tom/graal/mxtool/mx.py", line 343, in find_classes_with_matching_source_line for e in os.listdir(pkgOutputDir): OSError: [Errno 2] No such file or directory: '/home/tom/graal/graal/com.oracle.graal.compiler.hsail.test.lambda/bin/com/oracle/graal/compiler/hsail/test/lambda' -- Tom Deneau From doug.simon at oracle.com Fri May 10 14:28:48 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 10 May 2013 23:28:48 +0200 Subject: mx unittest with @javaCompliance=1.8 In-Reply-To: References: Message-ID: <8ACF9C9C-28C6-40F2-AB43-F31D0BD57F05@oracle.com> I'm pushing a change through now that should fix this. On May 10, 2013, at 10:23 PM, "Deneau, Tom" wrote: > We added a project locally here and marked it with @javaCompliance=1.8 > (test cases in this project use lambdas) > > With that annotation mx build product seems to work fine, it builds that project > if the java_home is 1.8, but not 1.7. And if 1.8 is used, we can > use mx unittest to run the test cases in that project. > > However, we had a user who was still using 1.7 and after updating to this new projects file, > got the following experience > >> mx build product # worked fine, did not built the 1.8 project > >> mx unittest IntSquaredTest > # note: IntSquaredTest is in one of the normal 1.7 projects > > got the error shown below. So it looks like unittest at least is ignoring > the fact that this project is 1.8 and looking for its bin directory even though > we are using a 1.7 jvm... > > > Traceback (most recent call last): > File "/home/tom/graal/mxtool/mx.py", line 3191, in > main() > File "/home/tom/graal/mxtool/mx.py", line 3180, in main > retcode = c(command_args) > File "/home/tom/graal/mx/commands.py", line 839, in unittest > _unittest(args, ['@Test', '@LongTest']) > File "/home/tom/graal/mx/commands.py", line 827, in _unittest > _run_tests(args, harness, annotations, testfile) > File "/home/tom/graal/mx/commands.py", line 791, in _run_tests > classes += _find_classes_with_annotations(p, None, annotations).keys() > File "/home/tom/graal/mx/commands.py", line 776, in _find_classes_with_annotations > return p.find_classes_with_matching_source_line(pkgRoot, matches, includeInnerClasses) > File "/home/tom/graal/mxtool/mx.py", line 343, in find_classes_with_matching_source_line > for e in os.listdir(pkgOutputDir): > OSError: [Errno 2] No such file or directory: '/home/tom/graal/graal/com.oracle.graal.compiler.hsail.test.lambda/bin/com/oracle/graal/compiler/hsail/test/lambda' > > -- Tom Deneau > > From doug.simon at oracle.com Fri May 10 15:04:05 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 10 May 2013 22:04:05 +0000 Subject: hg: graal/graal: 82 new changesets Message-ID: <20130510221119.D3308489F5@hg.openjdk.java.net> Changeset: 1e171a158660 Author: Doug Simon Date: 2013-05-03 14:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1e171a158660 linked documentation about the exception handler stub calling convention with the x64 interpreter source ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java Changeset: b4e7de9a13b1 Author: Doug Simon Date: 2013-05-04 22:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b4e7de9a13b1 use ControlSinkNode (instead of subclass) when establishing a forward graph order ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ControlSinkNode.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/GraphOrder.java Changeset: 08d1414ac62d Author: Doug Simon Date: 2013-05-04 22:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/08d1414ac62d refactored common code in subclasses into AMD64HotSpotEpilogueOp ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotEpilogueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotReturnOp.java Changeset: 85595218dab0 Author: Doug Simon Date: 2013-05-04 22:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/85595218dab0 added compare between address and 32-bit immediate ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java Changeset: 99ef9bcb3f32 Author: Doug Simon Date: 2013-05-04 23:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/99ef9bcb3f32 replaced unwind_exception_call assembler stub with a compiled stub (GRAAL-81) + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotJumpToExceptionHandlerInCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotUnwindOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/JumpToExceptionHandlerInCallerNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/UnwindNode.java + graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/UnwindExceptionToCallerTest.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 325b394bc535 Author: Doug Simon Date: 2013-05-04 23:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/325b394bc535 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: a1ba00323cc2 Author: Doug Simon Date: 2013-05-05 00:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a1ba00323cc2 removed unused import ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 3d3da5a588bb Author: Doug Simon Date: 2013-05-05 00:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3d3da5a588bb removed instance of unwind_exception_call_id from ASSERT code ! src/share/vm/graal/graalRuntime.cpp Changeset: 7207028ce060 Author: Doug Simon Date: 2013-05-05 17:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7207028ce060 ensure frame is fully restored when unwinding to exception handler in caller's frame ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotJumpToExceptionHandlerInCallerOp.java Changeset: a8b4f26d8485 Author: Doug Simon Date: 2013-05-05 17:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a8b4f26d8485 removed Stub.log(...) methods ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: f64a3fec4e42 Author: Doug Simon Date: 2013-05-06 12:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f64a3fec4e42 exception PC stored in thread is cleared when retrieving continuation for a return address ! src/share/vm/runtime/sharedRuntime.cpp Changeset: c9e9ce8ce16a Author: Gilles Duboscq Date: 2013-05-06 13:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c9e9ce8ce16a Fix overflow guard condition for down counted loops Add assert in expand logic phase ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/CountedLoopInfo.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ExpandLogicPhase.java Changeset: 314814fa0223 Author: Christian Haeubl Date: 2013-05-06 14:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/314814fa0223 record deopts on the root method ! src/share/vm/runtime/deoptimization.cpp Changeset: f0ef8f58a1d9 Author: Gilles Duboscq Date: 2013-05-06 15:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f0ef8f58a1d9 Use root method for deopt reason collecting if possible in non-graalvm ! src/share/vm/runtime/deoptimization.cpp Changeset: d6bf345d58c1 Author: Gilles Duboscq Date: 2013-05-06 15:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d6bf345d58c1 Merge Changeset: a79e8020ad4b Author: Doug Simon Date: 2013-05-06 13:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a79e8020ad4b added Stub.decipher() to print information about values in stubs ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! src/share/vm/graal/graalRuntime.cpp Changeset: df3aa336a313 Author: Doug Simon Date: 2013-05-06 14:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/df3aa336a313 replaced verify_oop assembler stub with a compiled stub (GRAAL-81) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp - src/cpu/x86/vm/graalStubAssembler_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 50779b21024b Author: Doug Simon Date: 2013-05-06 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/50779b21024b modified PiPushable implementation for IsNullNode to account for an input that is an unsafe cast from a word value ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/IsNullNode.java Changeset: e799f8478b6d Author: Doug Simon Date: 2013-05-06 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e799f8478b6d re-enabled object verification for NewArrayStub and NewInstanceStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java Changeset: ffd3d85e055f Author: Doug Simon Date: 2013-05-06 15:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ffd3d85e055f replaced OSR_migration_end assembler stub with a compiled stub (GRAAL-81) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 5cf60de9d7d2 Author: Doug Simon Date: 2013-05-06 16:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5cf60de9d7d2 Merge. Changeset: ff153f4ae48b Author: Doug Simon Date: 2013-05-06 16:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff153f4ae48b removed debug output ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java Changeset: c59beafffb29 Author: Doug Simon Date: 2013-05-06 21:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c59beafffb29 added use of javadoc links ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.java Changeset: d84ea522800e Author: Doug Simon Date: 2013-05-06 22:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d84ea522800e replaced arithmetic_[fd]rem stubs with inline compiled code (GRAAL-81) ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64MacroAssembler.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 7df076e74e8e Author: Doug Simon Date: 2013-05-06 22:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7df076e74e8e fixed bug in updating of VerifyOops counter ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: c382fa74b1ee Author: twisti Date: 2013-05-06 14:17 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/c382fa74b1ee remove basicTypes and basicTypeCount ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 4172233f32fd Author: twisti Date: 2013-05-06 15:15 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/4172233f32fd make lookupConstantInPool use ConstantPool logic ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 404eb9b2c511 Author: twisti Date: 2013-05-06 16:52 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/404eb9b2c511 use os.name property to identify Windows OS ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: c064c48b9387 Author: Lukas Stadler Date: 2013-05-06 16:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c064c48b9387 fix virtualization of ObjectEqualsNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java Changeset: c84eb4661fe9 Author: Lukas Stadler Date: 2013-05-06 18:25 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c84eb4661fe9 Merge - src/cpu/x86/vm/graalStubAssembler_x86.cpp Changeset: 65de4389f3ed Author: Lukas Stadler Date: 2013-05-06 18:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/65de4389f3ed fix multiplication by small constant value (fixes assertion error) ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java Changeset: 08af000f4b69 Author: Lukas Stadler Date: 2013-05-07 10:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/08af000f4b69 Merge ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java Changeset: 5f9c41cd3b1e Author: Doug Simon Date: 2013-05-06 22:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5f9c41cd3b1e replaced monitorenter/monitorexit assembler stubs with compiled stubs (GRAAL-81) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorEnterStub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorExitStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 0381c7937e7a Author: Doug Simon Date: 2013-05-06 23:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0381c7937e7a replaced create_null_pointer_exception assembler stub with compiled stub (GRAAL-81) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateNullPointerExceptionStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: efb8c1918ea5 Author: Doug Simon Date: 2013-05-06 23:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/efb8c1918ea5 replaced create_out_of_bounds_exception assembler stub with compiled stub (GRAAL-81) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateOutOfBoundsExceptionStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: a3b4bcc22313 Author: Doug Simon Date: 2013-05-07 00:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a3b4bcc22313 replaced log_* assembler stubs with compiled stubs (GRAAL-81) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 743326387173 Author: Doug Simon Date: 2013-05-07 01:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/743326387173 replaced vm_error assembler stub with compiled stub (GRAAL-81) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: db2125285960 Author: Doug Simon Date: 2013-05-07 01:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/db2125285960 replaced wb_pre_call and wb_post_call assembler stubs with compiled stubs (GRAAL-81) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPostStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPreStubCall.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPostStub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPreStub.java ! src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: aa8f3fc0a9a9 Author: Doug Simon Date: 2013-05-07 01:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aa8f3fc0a9a9 removed infrastructure for Graal assembler stubs (GRAAL-81) - src/cpu/x86/vm/graalRuntime_x86.cpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: d5c2b20e9d73 Author: Doug Simon Date: 2013-05-07 01:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d5c2b20e9d73 Merge. ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 0fc67e300471 Author: Doug Simon Date: 2013-05-07 11:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0fc67e300471 better help message for the unittest commands ! mx/commands.py Changeset: ffbb0a365039 Author: Doug Simon Date: 2013-05-07 11:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ffbb0a365039 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 20c09d314168 Author: Gilles Duboscq Date: 2013-05-07 14:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/20c09d314168 Improve markFloating in LoopFragment (avoids recursion explosion) ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java Changeset: 278a50fb49c7 Author: Christian Wimmer Date: 2013-05-07 11:12 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/278a50fb49c7 Create a LoadFieldNode for a getstatic of a static final field in the graph builder, and rely on the canonicalizer for replacing it with the constant value. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SnippetLocationNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 19c5a07c7843 Author: Christian Wimmer Date: 2013-05-07 12:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/19c5a07c7843 Introduce a graph() method that returns a StructuredGraph, to make many explicit casts unnecessary ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CStringNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotInstalledCodeExecuteNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CallSiteTargetNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ReflectionGetCallerClassNode.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/CountedLoopInfo.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragmentInside.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopTransformations.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.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/ScheduledNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ConditionalNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/NormalizeCompareNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/DynamicCounterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/debug/SurvivingCounterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IntegerSwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.replacements.amd64/src/com/oracle/graal/replacements/amd64/AMD64ConvertSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeIntrinsificationVerificationPhase.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectObjectStoreNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/CyclicMaterializeStoreNode.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: c010001c38ce Author: Doug Simon Date: 2013-05-07 21:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c010001c38ce updated javadoc for HotSpotInstalledCode to document why the nmethod::_graal_installed_code can only be a weak reference ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotInstalledCode.java Changeset: 8fe7e6e7b443 Author: Doug Simon Date: 2013-05-07 21:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8fe7e6e7b443 javadoc fix ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java Changeset: 1a87230c775d Author: Doug Simon Date: 2013-05-07 22:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1a87230c775d removed embedding of compiler creating objects into installed code (HotSpot cannot support this) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java Changeset: 0f7bd899a1a8 Author: Lukas Stadler Date: 2013-05-08 11:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0f7bd899a1a8 make ObjectEqualsNode virtualization less conservative ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java Changeset: 6f208669893a Author: Lukas Stadler Date: 2013-05-08 11:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6f208669893a add UnsafeArrayCastNode constructor without anchor ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeArrayCastNode.java Changeset: 7a330743a452 Author: Lukas Stadler Date: 2013-05-08 11:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7a330743a452 change visibility of createFieldLocation/createArrayLocation ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: c0d76a2ef720 Author: Lukas Stadler Date: 2013-05-08 13:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c0d76a2ef720 small change to ControlFlowGraph assertion ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/ControlFlowGraph.java Changeset: ae17e540c5d2 Author: Gilles Duboscq Date: 2013-05-08 16:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ae17e540c5d2 More asserts while getting vtable offsets Added check that methods have vtable entrys before using method dispatch instead of type dispatch ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! 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/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadMethodNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: fb3ed8e444ea Author: Christian Wimmer Date: 2013-05-08 13:07 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/fb3ed8e444ea Method can be static ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/AbstractTest.java Changeset: 66db0353f55a Author: Doug Simon Date: 2013-05-07 23:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/66db0353f55a compilation is explicitly given a CallingConvention for the graph being compiled instead of deriving it from a method ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeUtil.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! 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.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: 0c17815817a4 Author: Doug Simon Date: 2013-05-08 12:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0c17815817a4 removed LIRGenerator.method field ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! 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.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/StubStartNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: 59ec6eb8612e Author: Doug Simon Date: 2013-05-08 12:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/59ec6eb8612e removed LinearScan.method field ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! 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: 1089d63ef168 Author: Doug Simon Date: 2013-05-08 14:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1089d63ef168 removed 'method' parameter from GraalCompiler.compiledMethod() and renamed the latter to 'compileGraph'. ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java Changeset: ff62d13ad3e7 Author: Doug Simon Date: 2013-05-08 18:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff62d13ad3e7 removed mapping from methods to stubs in HotSpotRuntime in preparation for stubs that are not associated with a method ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: c1ef2bf6848e Author: Doug Simon Date: 2013-05-08 20:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c1ef2bf6848e removed the requirement that a compiled stub is implemented by a snippet ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CRuntimeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: bd4a7d657dcc Author: Doug Simon Date: 2013-05-08 21:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bd4a7d657dcc moved static methods out of Stub into StubUtil ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateNullPointerExceptionStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateOutOfBoundsExceptionStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/IdentityHashCodeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorEnterStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorExitStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RegisterFinalizerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPostStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPreStub.java Changeset: 5e3c8dd80632 Author: Doug Simon Date: 2013-05-08 21:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5e3c8dd80632 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 0eda2b7df748 Author: Doug Simon Date: 2013-05-08 21:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0eda2b7df748 fixed debug scope processing so that -G:MethodFilter option works as expected ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java Changeset: e97dc9bbfedc Author: Doug Simon Date: 2013-05-08 22:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e97dc9bbfedc introduced installedCodeOwner parameter of type ResolvedJavaMethod to GraalCompiler.compileGraph to properly distinguish the source method of a graph from the method under which the code compiled for the graph will be installed ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXBackend.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: ac96c2062de4 Author: Doug Simon Date: 2013-05-08 22:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ac96c2062de4 Merge. Changeset: 76c40c3f6bb7 Author: Lukas Stadler Date: 2013-05-08 15:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/76c40c3f6bb7 let ReentrantNodeIterator.processNode return the next state ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantNodeIterator.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetFrameStateCleanupPhase.java Changeset: 87eafaddf9d9 Author: Lukas Stadler Date: 2013-05-08 18:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/87eafaddf9d9 let ReentrantBlockIterator.processBlock return the next state ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantBlockIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: bce1c7759d9d Author: Lukas Stadler Date: 2013-05-09 11:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/bce1c7759d9d Merge Changeset: 29abc1e22280 Author: Bernhard Urban Date: 2013-05-09 23:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/29abc1e22280 AllocatorTest: relax counting-condition for MoveOp makes a regression, which was introduced by commit 688219709f7b, more obvious. ! graal/com.oracle.graal.compiler.amd64.test/src/com/oracle/graal/compiler/amd64/test/AMD64AllocatorTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java Changeset: 1a009b20f816 Author: Morris Meyer Date: 2013-05-09 21:07 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/1a009b20f816 broaden Apple include for gpu_bsd, make TraceWarpLoading a product flag ! src/os/bsd/vm/gpu_bsd.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8851fabf2265 Author: Thomas Wuerthinger Date: 2013-05-09 19:21 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/8851fabf2265 LinearScan: Can no longer check for object equality after removal of RegisterValue cache. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java Changeset: f7e06c106dda Author: Thomas Wuerthinger Date: 2013-05-09 19:37 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/f7e06c106dda Merge. Changeset: cd0c173593a8 Author: Thomas Wuerthinger Date: 2013-05-09 21:08 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/cd0c173593a8 Fix too specific return type. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/virtual/VirtualArrayNode.java Changeset: 3c9aeef2702c Author: Bernhard Urban Date: 2013-05-10 12:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3c9aeef2702c Value: provide proper `hashCode()' and `equals()' implementations ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RegisterValue.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/StackSlot.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Value.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMonitorValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/Variable.java Changeset: 97db51025787 Author: Bernhard Urban Date: 2013-05-10 12:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/97db51025787 Value: use `equals()' instead of object equality 8841fab and this changeset fixes a regression introduced by 688219 (removed cached RegisterValues) ! graal/com.oracle.graal.compiler.amd64.test/src/com/oracle/graal/compiler/amd64/test/AMD64AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/EdgeMoveOptimizer.java Changeset: 5207bb46598e Author: Lukas Stadler Date: 2013-05-10 13:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5207bb46598e simplify "clever" code in FrameStateAssignmentPhase ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java Changeset: f3dfca9fd0b3 Author: Lukas Stadler Date: 2013-05-10 13:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f3dfca9fd0b3 PEA: replace customAction with addNode (GRAAL-260) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/ObjectEqualsNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/VirtualizerTool.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: dac93aca017b Author: Lukas Stadler Date: 2013-05-10 13:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dac93aca017b PEA: remove obsolete CyclicMaterializeStoreNode - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/CyclicMaterializeStoreNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: ff4e8218d3dd Author: Gilles Duboscq Date: 2013-05-10 12:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff4e8218d3dd Remove hasVtableEntry, use isInVirtualMethodTable instead ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: f38f746f4980 Author: Bernhard Urban Date: 2013-05-10 16:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f38f746f4980 JUnitWrapper: print class name if only one testclass is executed ! mx/JUnitWrapper.java Changeset: c455c86138ba Author: Bernhard Urban Date: 2013-05-10 16:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c455c86138ba Value: more occurrences of object equality replaced In order to verify, I implemented a small verification phase and used CTW to compile graal.jar. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CallingConvention.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ValueUtil.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotUnwindOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64AddressValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRVerifier.java Changeset: fde5ccbab3a3 Author: Doug Simon Date: 2013-05-10 23:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fde5ccbab3a3 made unittest command take Java compliance of a project into account ! mx/commands.py From christian.thalinger at oracle.com Mon May 13 21:59:49 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 May 2013 21:59:49 -0700 Subject: RFR (L): implement inlining support for JSR 292 Message-ID: http://cr.openjdk.java.net/~twisti/GRAAL-249/webrev/ This adds inlining support of method handle invokes. However, the patch is missing a little piece that is required so that calls are actually inlined. That little change needs some bigger changes in Graal itself so I cannot push it right now. Thomas knows about this issue and I hope he (or someone else) will fix it soon. Here are some JRuby and Nashorn numbers (with the little change, obviously): $ bin/jruby.sh -J-showversion ../rubybench/time/bench_fib_recursive.rb 5 35 java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b88) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b30, mixed mode) 1.080000 0.000000 1.080000 ( 0.996000) 0.850000 0.000000 0.850000 ( 0.826000) 0.830000 0.000000 0.830000 ( 0.827000) 0.820000 0.010000 0.830000 ( 0.823000) 0.860000 0.000000 0.860000 ( 0.830000) $ bin/jruby.sh -J-showversion ../rubybench/time/bench_fib_recursive.rb 5 35 Bootstrapping Graal............................ in 20527 ms java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b88) OpenJDK 64-Bit Graal VM (build 25.0-b29-internal, mixed mode) 91.040000 0.280000 91.320000 ( 12.076000) 0.830000 0.000000 0.830000 ( 0.678000) 0.900000 0.100000 1.000000 ( 0.666000) 0.660000 0.000000 0.660000 ( 0.659000) 0.660000 0.000000 0.660000 ( 0.664000) $ java -showversion -jar dist/nashorn.jar test/script/basic/run-octane.js -- test/script/external/octane/richards.js --iterations 10 --verbose java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b88) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b30, mixed mode) command line: running richards.js... Score: 498 Score: 1774 Score: 1968 Score: 2005 Score: 2111 Score: 2150 Score: 2125 Score: 2127 Score: 2115 Score: 2196 command line: Richards (version 8): 498-2196 $ java -showversion -jar dist/nashorn.jar test/script/basic/run-octane.js -- test/script/external/octane/richards.js --iterations 10 --verbose Bootstrapping Graal............................ in 20774 ms java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b88) OpenJDK 64-Bit Graal VM (build 25.0-b29-internal, mixed mode) command line: running richards.js... Score: 66.4 Score: 1471 Score: 1452 Score: 1668 Score: 1675 Score: 1677 Score: 1534 Score: 1705 Score: 1709 Score: 1703 command line: Richards (version 8): 66.4-1709 From thomas.wuerthinger at oracle.com Tue May 14 01:30:29 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 14 May 2013 01:30:29 -0700 Subject: RFR (L): implement inlining support for JSR 292 In-Reply-To: References: Message-ID: This looks great - thanks for the contribution! Could you actually push your patch anyway? I think it should pass the gate (as we do not _yet_ exercise invokedynamic there). We will subsequently fix the order of canonicalization and scanning for new invokes in the inlining phase. Good to see that even without any fine tuning, the performance looks already promising ;). - thomas On May 13, 2013, at 9:59 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/GRAAL-249/webrev/ > > This adds inlining support of method handle invokes. > > However, the patch is missing a little piece that is required so that calls are actually inlined. That little change needs some bigger changes in Graal itself so I cannot push it right now. Thomas knows about this issue and I hope he (or someone else) will fix it soon. > > Here are some JRuby and Nashorn numbers (with the little change, obviously): > > $ bin/jruby.sh -J-showversion ../rubybench/time/bench_fib_recursive.rb 5 35 > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b88) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b30, mixed mode) > > 1.080000 0.000000 1.080000 ( 0.996000) > 0.850000 0.000000 0.850000 ( 0.826000) > 0.830000 0.000000 0.830000 ( 0.827000) > 0.820000 0.010000 0.830000 ( 0.823000) > 0.860000 0.000000 0.860000 ( 0.830000) > > $ bin/jruby.sh -J-showversion ../rubybench/time/bench_fib_recursive.rb 5 35 > Bootstrapping Graal............................ in 20527 ms > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b88) > OpenJDK 64-Bit Graal VM (build 25.0-b29-internal, mixed mode) > > 91.040000 0.280000 91.320000 ( 12.076000) > 0.830000 0.000000 0.830000 ( 0.678000) > 0.900000 0.100000 1.000000 ( 0.666000) > 0.660000 0.000000 0.660000 ( 0.659000) > 0.660000 0.000000 0.660000 ( 0.664000) > > $ java -showversion -jar dist/nashorn.jar test/script/basic/run-octane.js -- test/script/external/octane/richards.js --iterations 10 --verbose > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b88) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b30, mixed mode) > > command line: running richards.js... > Score: 498 > Score: 1774 > Score: 1968 > Score: 2005 > Score: 2111 > Score: 2150 > Score: 2125 > Score: 2127 > Score: 2115 > Score: 2196 > command line: Richards (version 8): 498-2196 > > $ java -showversion -jar dist/nashorn.jar test/script/basic/run-octane.js -- test/script/external/octane/richards.js --iterations 10 --verbose > Bootstrapping Graal............................ in 20774 ms > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b88) > OpenJDK 64-Bit Graal VM (build 25.0-b29-internal, mixed mode) > > command line: running richards.js... > Score: 66.4 > Score: 1471 > Score: 1452 > Score: 1668 > Score: 1675 > Score: 1677 > Score: 1534 > Score: 1705 > Score: 1709 > Score: 1703 > command line: Richards (version 8): 66.4-1709 > From tom.deneau at amd.com Thu May 16 08:37:06 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 16 May 2013 15:37:06 +0000 Subject: accessing a static field Message-ID: In our graal HSAIL compiler, we would like to be able to compile accesses of a static field. I can see that we are generating a MoveToRegOp with the result being a register and the input being a Constant of kind = Object, the Object being the class object which contains the static field. and I think we want to end up with code like: mov_b64 $d1, constant_address_of_class; ld_global_s32 $s1, [$d1 + 148]; The second instruction is being correctly generated but for the first instruction how do I in java get the actual constant address to insert in the instruction, given the class Object? (I am assuming the address of the class really does remain constant in the face of GC) I glanced at the AMD64 code and I don't really understand what is going on with the recordDataReferenceInCode logic. -- Tom Deneau, AMD From doug.simon at oracle.com Thu May 16 09:31:04 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 May 2013 18:31:04 +0200 Subject: accessing a static field In-Reply-To: References: Message-ID: <23F0FDBB-CD8E-4D53-B6FC-07B47FDF7D44@oracle.com> On May 16, 2013, at 5:37 PM, "Deneau, Tom" wrote: > In our graal HSAIL compiler, we would like to be able to compile accesses of a static field. > I can see that we are generating a MoveToRegOp with the result being a register and the input > being a Constant of kind = Object, the Object being the class object which contains the static field. > > and I think we want to end up with code like: > > mov_b64 $d1, constant_address_of_class; > ld_global_s32 $s1, [$d1 + 148]; > > The second instruction is being correctly generated but for the first instruction how do I > in java get the actual constant address to insert in the instruction, given the class Object? > (I am assuming the address of the class really does remain constant in the face of GC) > > I glanced at the AMD64 code and I don't really understand what is going on with the > recordDataReferenceInCode logic. The recordDataReferenceInCode creates a patch record that the C++ layer uses to embed the oop (of the java.lang.Class instance in your case) in the instruction stream. This cannot be done until the necessary metadata describing embedded oops has been created. These embedded oops are only constant from the code's perspective, not from the GC's perspective. Have you looked at the code starting at AMD64Move.java:488? This is how oops are embedded in AMD64 code and will hopefully instruct how you can do likewise for the HSAIL backend. The critical thing is to ensure the GC knows where the embedded oops are. -Doug From tom.deneau at amd.com Thu May 16 09:40:14 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 16 May 2013 16:40:14 +0000 Subject: accessing a static field In-Reply-To: <23F0FDBB-CD8E-4D53-B6FC-07B47FDF7D44@oracle.com> References: <23F0FDBB-CD8E-4D53-B6FC-07B47FDF7D44@oracle.com> Message-ID: Doug -- Are you saying the GC might have to patch the code multiple times (i.e, every time the class object has moved)? We were counting on being able to generate the code once (as source), compile it and use the compiled code without change. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, May 16, 2013 11:31 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: accessing a static field On May 16, 2013, at 5:37 PM, "Deneau, Tom" wrote: > In our graal HSAIL compiler, we would like to be able to compile accesses of a static field. > I can see that we are generating a MoveToRegOp with the result being a register and the input > being a Constant of kind = Object, the Object being the class object which contains the static field. > > and I think we want to end up with code like: > > mov_b64 $d1, constant_address_of_class; > ld_global_s32 $s1, [$d1 + 148]; > > The second instruction is being correctly generated but for the first instruction how do I > in java get the actual constant address to insert in the instruction, given the class Object? > (I am assuming the address of the class really does remain constant in the face of GC) > > I glanced at the AMD64 code and I don't really understand what is going on with the > recordDataReferenceInCode logic. The recordDataReferenceInCode creates a patch record that the C++ layer uses to embed the oop (of the java.lang.Class instance in your case) in the instruction stream. This cannot be done until the necessary metadata describing embedded oops has been created. These embedded oops are only constant from the code's perspective, not from the GC's perspective. Have you looked at the code starting at AMD64Move.java:488? This is how oops are embedded in AMD64 code and will hopefully instruct how you can do likewise for the HSAIL backend. The critical thing is to ensure the GC knows where the embedded oops are. -Doug From doug.simon at oracle.com Thu May 16 09:54:33 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 May 2013 18:54:33 +0200 Subject: accessing a static field In-Reply-To: References: <23F0FDBB-CD8E-4D53-B6FC-07B47FDF7D44@oracle.com> Message-ID: On May 16, 2013, at 6:40 PM, "Deneau, Tom" wrote: > Doug -- > > Are you saying the GC might have to patch the code multiple times (i.e, every time the class object has moved)? > We were counting on being able to generate the code once (as source), compile it and use the compiled code without change. After the removal of the permgen from HotSpot, all static fields hang off the java.lang.Class instance which is a normal heap object. This means it can move. So, what you are trying to achieve unfortunately won't work (to the best of my knowledge). -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, May 16, 2013 11:31 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: accessing a static field > > > On May 16, 2013, at 5:37 PM, "Deneau, Tom" wrote: > >> In our graal HSAIL compiler, we would like to be able to compile accesses of a static field. >> I can see that we are generating a MoveToRegOp with the result being a register and the input >> being a Constant of kind = Object, the Object being the class object which contains the static field. >> >> and I think we want to end up with code like: >> >> mov_b64 $d1, constant_address_of_class; >> ld_global_s32 $s1, [$d1 + 148]; >> >> The second instruction is being correctly generated but for the first instruction how do I >> in java get the actual constant address to insert in the instruction, given the class Object? >> (I am assuming the address of the class really does remain constant in the face of GC) >> >> I glanced at the AMD64 code and I don't really understand what is going on with the >> recordDataReferenceInCode logic. > > The recordDataReferenceInCode creates a patch record that the C++ layer uses to embed the oop (of the java.lang.Class instance in your case) in the instruction stream. This cannot be done until the necessary metadata describing embedded oops has been created. These embedded oops are only constant from the code's perspective, not from the GC's perspective. > > Have you looked at the code starting at AMD64Move.java:488? This is how oops are embedded in AMD64 code and will hopefully instruct how you can do likewise for the HSAIL backend. The critical thing is to ensure the GC knows where the embedded oops are. > > -Doug > From christian.thalinger at oracle.com Thu May 16 16:00:45 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 May 2013 16:00:45 -0700 Subject: RFR (S): use invoker's stamp if target's return stamp is of different type Message-ID: This is a fix for 292. -- Chris diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java @@ -273,9 +273,20 @@ ValueNode[] args = replacementArguments.toArray(new ValueNode[replacementArguments.size()]); callTarget = new SelfReplacingMethodCallTargetNode(invokeKind, targetMethod, targetArguments, returnType, replacementTargetMethod, args, replacementReturnType); } + graph().add(callTarget); - graph().add(callTarget); - InvokeNode invoke = graph().add(new InvokeNode(callTarget, getBci())); + // The call target can have a different return type than the invoker, + // e.g. the target returns an Object but the invoker void. In this case + // we need to use the stamp of the invoker. Note: always using the + // invoker's stamp would be wrong because it's a less concrete type + // (usually java.lang.Object). + InvokeNode invoke; + if (callTarget.returnStamp().kind() != stamp().kind()) { + invoke = new InvokeNode(callTarget, getBci(), stamp()); + } else { + invoke = new InvokeNode(callTarget, getBci()); + } + graph().add(invoke); invoke.setStateAfter(stateAfter()); return invoke; } diff --git a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java --- a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java +++ b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java @@ -29,6 +29,7 @@ import com.oracle.graal.nodes.extended.*; import com.oracle.graal.nodes.extended.LocationNode.LocationIdentity; import com.oracle.graal.nodes.spi.*; +import com.oracle.graal.nodes.type.Stamp; import com.oracle.graal.nodes.util.*; /** @@ -47,11 +48,22 @@ /** * Constructs a new Invoke instruction. * + * @param callTarget the target method being called * @param bci the bytecode index of the original invoke (used for debug infos) - * @param callTarget the target method being called */ public InvokeNode(CallTargetNode callTarget, int bci) { - super(callTarget.returnStamp()); + this(callTarget, bci, callTarget.returnStamp()); + } + + /** + * Constructs a new Invoke instruction. + * + * @param callTarget the target method being called + * @param bci the bytecode index of the original invoke (used for debug infos) + * @param stamp the stamp to be used for this value + */ + public InvokeNode(CallTargetNode callTarget, int bci, Stamp stamp) { + super(stamp); this.callTarget = callTarget; this.bci = bci; this.polymorphic = false; From tom.deneau at amd.com Fri May 17 16:45:30 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 17 May 2013 23:45:30 +0000 Subject: inline everything Message-ID: Is there a flag that will make Graal inline everything regardless of size or other policies? When I tried increasing MaximumDesiredSize I still saw nodes generated like the following at node: 12|Invoke#Direct#computeAcc -- Tom From thomas.wuerthinger at oracle.com Fri May 17 17:30:32 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 17 May 2013 17:30:32 -0700 Subject: inline everything In-Reply-To: References: Message-ID: <9C7D200F-C644-4019-A333-CCDB0DD33A8B@oracle.com> Currently, this is not possible, but we can easily add that. Graal does not inline if it believes based on the probability of the invoke and the complexity of the called method that inlining is not worth it. So, you would like to see a version of Graal that inlines everything and throws a bailout exception if either the maximum desired size is exceeded or if there is still an invoke left that cannot be inlined (e.g., because it is megamorphic)? - thomas On May 17, 2013, at 4:45 PM, "Deneau, Tom" wrote: > Is there a flag that will make Graal inline everything regardless of size or other policies? > When I tried increasing MaximumDesiredSize I still saw nodes generated like the following > > at node: 12|Invoke#Direct#computeAcc > > -- Tom > From tom.deneau at amd.com Fri May 17 18:06:54 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Sat, 18 May 2013 01:06:54 +0000 Subject: inline everything In-Reply-To: <9C7D200F-C644-4019-A333-CCDB0DD33A8B@oracle.com> References: <9C7D200F-C644-4019-A333-CCDB0DD33A8B@oracle.com> Message-ID: I think so. This would be a stopgap until we can handle method call nodes... -- Tom -----Original Message----- From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] Sent: Friday, May 17, 2013 7:31 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: inline everything Currently, this is not possible, but we can easily add that. Graal does not inline if it believes based on the probability of the invoke and the complexity of the called method that inlining is not worth it. So, you would like to see a version of Graal that inlines everything and throws a bailout exception if either the maximum desired size is exceeded or if there is still an invoke left that cannot be inlined (e.g., because it is megamorphic)? - thomas On May 17, 2013, at 4:45 PM, "Deneau, Tom" wrote: > Is there a flag that will make Graal inline everything regardless of size or other policies? > When I tried increasing MaximumDesiredSize I still saw nodes generated like the following > > at node: 12|Invoke#Direct#computeAcc > > -- Tom > From doug.simon at oracle.com Sat May 18 18:00:38 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 19 May 2013 01:00:38 +0000 Subject: hg: graal/graal: 135 new changesets Message-ID: <20130519013953.4453A48B9E@hg.openjdk.java.net> Changeset: 65d7696fb58a Author: Bernhard Urban Date: 2013-05-10 21:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/65d7696fb58a Value: tidy up generated `hashCode()' and `equals()' methods a bit ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RegisterValue.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/StackSlot.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Value.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMonitorValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/CompositeValue.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/Variable.java Changeset: 5e8299154973 Author: Bernhard Urban Date: 2013-05-13 11:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5e8299154973 verification: add VerifyPhase. check if a `Value' object is used in an ObjectEqualsNode ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/VerifyPhase.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyValueUsage.java Changeset: 6320d0e541b4 Author: Bernhard Urban Date: 2013-05-13 11:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6320d0e541b4 Value: replaced more occurrences where object equality is used ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java Changeset: afc3e97391bf Author: Gilles Duboscq Date: 2013-05-10 16:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/afc3e97391bf In TailDuplication phase, replaced phi values users should not need to be anchored ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java Changeset: a230bfbd9497 Author: Gilles Duboscq Date: 2013-05-10 17:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a230bfbd9497 Use specialized node inputs for loopbegin's overflow check and for value anchor's anchored values ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/CountedLoopInfo.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopSafepointEliminationPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java Changeset: 37e996855762 Author: Gilles Duboscq Date: 2013-05-10 18:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/37e996855762 Allow interface types for node edges ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 183d33c76419 Author: Gilles Duboscq Date: 2013-05-10 18:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/183d33c76419 Removed ValueNode.dependencies Introduced GuardedNode and GuardingNode interfaces ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/CountedLoopInfo.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/AbstractBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingFixedWithNextNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedWithNextNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FloatingGuardedNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/Invoke.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LogicNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/LoopBeginNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/FloatingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/Access.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatableAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/GuardedNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/GuardingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/NullCheckNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringTool.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/EliminatePartiallyRedundantGuardsPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 2adfe940fd55 Author: Gilles Duboscq Date: 2013-05-13 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2adfe940fd55 Make PiNode a guarding node so that it can be used for guarded to guarding edges PiNode should work for non-object values ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java Changeset: 309181f26fc7 Author: Gilles Duboscq Date: 2013-05-13 13:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/309181f26fc7 Merge Changeset: dd62ccda1849 Author: Doug Simon Date: 2013-05-13 10:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/dd62ccda1849 rename parameter ! 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 ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 8f9439edcf5b Author: Doug Simon Date: 2013-05-13 10:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8f9439edcf5b prevent multiple method context objects for the same method from resulting in multiple IGV tree levels unless there the method actually inlines itself ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/GraphPrinterDumpHandler.java Changeset: 5d9b5cf6df2b Author: Doug Simon Date: 2013-05-13 10:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5d9b5cf6df2b javadoc fix ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MemoryCheckpoint.java Changeset: e5533d2d40a3 Author: Doug Simon Date: 2013-05-13 11:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e5533d2d40a3 update the start node of a StructuredGraph if it is replaced via replaceFixedWithFixed() ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java Changeset: 36e12fbbefdf Author: Doug Simon Date: 2013-05-13 11:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/36e12fbbefdf replaced unnecessary call to Stub.getMethod() with Stub.toString() ! graal/com.oracle.graal.asm.test/src/com/oracle/graal/asm/test/AssemblerTest.java Changeset: 18632807db02 Author: Doug Simon Date: 2013-05-13 11:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/18632807db02 RuntimeStub installation support is now more distinct from normal nmethod installation ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompilationResult.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotInstalledCode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: 0a771345825b Author: Doug Simon Date: 2013-05-13 11:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0a771345825b added RuntimeCallStub for runtime calls that require no extra/special logic in the stub itself + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java Changeset: 53cbcd9ff217 Author: Doug Simon Date: 2013-05-13 11:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/53cbcd9ff217 replaced IdentityHashCodeStub[Call] with use of RuntimeStubCall ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/IdentityHashCodeStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/IdentityHashCodeStub.java Changeset: 4c162e218809 Author: Doug Simon Date: 2013-05-13 13:50 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4c162e218809 enabled creation of a HotSpotSignature from types (in addition to a string) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSignature.java Changeset: d64083db3c11 Author: Doug Simon Date: 2013-05-13 13:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d64083db3c11 changed CFGPrinterObserver to use JavaMethod instead of ResolvedJavaMethod for method scope ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/CFGPrinterObserver.java Changeset: c5b1b4dcc094 Author: Doug Simon Date: 2013-05-13 13:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c5b1b4dcc094 create fake JavaMethod for non-snippet stubs so that -G:MethodFilter can be applied to them ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java Changeset: c37c52445e75 Author: Doug Simon Date: 2013-05-13 13:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c37c52445e75 javadoc fixes ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: c6f3c1e48f54 Author: Doug Simon Date: 2013-05-13 13:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c6f3c1e48f54 better error message ! src/share/vm/graal/graalJavaAccess.cpp Changeset: eade47d311a3 Author: Doug Simon Date: 2013-05-13 14:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/eade47d311a3 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 822adbb2ee7b Author: Bernhard Urban Date: 2013-05-13 15:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/822adbb2ee7b CFGVerifier: verify post-dominator calculation verified against changeset 902a974d55c8, where post-dominator calculation was bogus. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/SimpleCFGTest.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/cfg/CFGVerifier.java Changeset: 843dde5a83af Author: Bernhard Urban Date: 2013-05-13 16:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/843dde5a83af VerifyValueUsage: move String creation to assert ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyValueUsage.java Changeset: 8f2f4c9e2dcf Author: Bernhard Urban Date: 2013-05-13 16:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8f2f4c9e2dcf VerifyValueUsage: use method name and signature instead of `toString()' ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyValueUsage.java Changeset: a886c764ea59 Author: Bernhard Urban Date: 2013-05-13 17:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a886c764ea59 Value: simplify some `equals' and `hashcode' implementations even more ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Value.java Changeset: 1ef7b26e9177 Author: Gilles Duboscq Date: 2013-05-13 16:09 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1ef7b26e9177 mx/commands.py: warn about arguments after '-version' when launching the vm ! mx/commands.py Changeset: fe9a18fbb15e Author: Doug Simon Date: 2013-05-13 18:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fe9a18fbb15e added subclasses for HotSpotInstalledCode: HotSpotNmethod and HotSpotRuntimeStub - graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotInstalledCodeTest.java + graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotNmethodTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotInstalledCode.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotNmethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntimeStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotInstalledCodeExecuteNode.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotInstalledCodeIntrinsics.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotInstalledCodeSubstitutions.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotNmethodIntrinsics.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotNmethodSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! make/build-graal.xml ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalEnv.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: ed6202820ecf Author: Doug Simon Date: 2013-05-13 21:59 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ed6202820ecf renamed HotSpotCompilationResult to HotSpotCompiledCode and added subclasses HotSpotCompiledNmethod and HotSpotCompiledRuntimeStub - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompilationResult.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledCode.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledNmethod.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledRuntimeStub.java ! 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/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/graalCompilerToGPU.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalJavaAccess.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: 86fa3d9f9fdd Author: Doug Simon Date: 2013-05-13 14:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/86fa3d9f9fdd replaced RegisterFinalizerStub with use of RuntimeStubCall ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RegisterFinalizerStub.java Changeset: 0b3d19e4e2a2 Author: Doug Simon Date: 2013-05-13 14:54 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0b3d19e4e2a2 used static import for methods in StubUtil ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateNullPointerExceptionStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateOutOfBoundsExceptionStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorEnterStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorExitStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPostStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPreStub.java Changeset: 67804a97c1ce Author: Doug Simon Date: 2013-05-13 19:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/67804a97c1ce allow inlining of invokes with a null stateAfter ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: 37ec49e1d7e2 Author: Doug Simon Date: 2013-05-13 19:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/37ec49e1d7e2 extended RuntimeCallStub to support calls returning an Object ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java Changeset: e897b58936aa Author: Doug Simon Date: 2013-05-13 19:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e897b58936aa replaced CreateNullPointerExceptionStub and CreateOutOfBoundsExceptionStub with use of RuntimeCallStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateNullPointerExceptionStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateOutOfBoundsExceptionStub.java Changeset: a54720257b76 Author: Doug Simon Date: 2013-05-13 22:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a54720257b76 replaced MonitorEnterStub and MonitorExitStub with use of RuntimeCallStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorEnterStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorExitStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: cd77bc78c409 Author: Doug Simon Date: 2013-05-13 22:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cd77bc78c409 Merge. - graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotInstalledCodeTest.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompilationResult.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotInstalledCodeExecuteNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotInstalledCodeIntrinsics.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotInstalledCodeSubstitutions.java Changeset: 1d9ab4f497ac Author: Roland Schatz Date: 2013-05-14 09:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1d9ab4f497ac Javadoc comments. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Architecture.java Changeset: 355611e0abe6 Author: Roland Schatz Date: 2013-05-14 09:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/355611e0abe6 Rename asAddress and make it protected. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java Changeset: 661dfb29b59b Author: Roland Schatz Date: 2013-05-14 09:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/661dfb29b59b Do a full canonicalization at the end of MidTier. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java Changeset: f7148150ae37 Author: Roland Schatz Date: 2013-05-14 09:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f7148150ae37 Relax kind equality assertions in LIRGenerator. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: f95f178b58c2 Author: Lukas Stadler Date: 2013-05-14 14:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f95f178b58c2 don't allocate new variables for NullCheckOps ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java Changeset: 86d24f120b78 Author: Roland Schatz Date: 2013-05-14 15:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/86d24f120b78 Allow tests to check for deoptimizations, provide Method object in before hook. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/JTTTest.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/hotpath/HP_field01.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/hotpath/HP_field03.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/jdk/Unsafe_compareAndSwap.java ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/loop/LoopNewInstance.java Changeset: 5a7a421aebfb Author: Doug Simon Date: 2013-05-14 11:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5a7a421aebfb fixed printf statements ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java Changeset: 35212baf46e5 Author: Doug Simon Date: 2013-05-14 11:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/35212baf46e5 added check that the graph inlined for an invoke with a null stateAfter contains only frame states whose bci is AFTER_BCI or INVALID_FRAMESTATE_BCI ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: aee2685c8d07 Author: Doug Simon Date: 2013-05-14 15:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/aee2685c8d07 Merge. Changeset: 69ac49574222 Author: Lukas Stadler Date: 2013-05-14 14:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/69ac49574222 PEA: virtualizing CommitAllocationNode and AllocatedObjectNode is not useful progress ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: a7376cc486ff Author: Lukas Stadler Date: 2013-05-14 14:48 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a7376cc486ff don't overwrite default entries when lowering CommitAllocationNodes ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 0d0645267c32 Author: Lukas Stadler Date: 2013-05-14 15:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0d0645267c32 simplify NewObjectSnippets ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/InitializeArrayNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/InitializeObjectNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TLABAllocateNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java Changeset: 120b2ac480b7 Author: Lukas Stadler Date: 2013-05-14 16:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/120b2ac480b7 Merge Changeset: a7f10828c4ff Author: Doug Simon Date: 2013-05-14 18:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a7f10828c4ff distinguish floating and fixed nodes when building a stub graph ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java Changeset: bd5c6b3dedc5 Author: twisti Date: 2013-05-14 11:27 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/bd5c6b3dedc5 implement inlining support for JSR 292 ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleInvokeBasicNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToInterfaceNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToSpecialNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToStaticNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MethodHandleLinkToVirtualNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/SelfReplacingMethodCallTargetNode.java Changeset: fb2cf3033ebb Author: Doug Simon Date: 2013-05-13 23:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/fb2cf3033ebb replaced WriteBarrierPreStub and WriteBarrierPostStub with use of RuntimeCallStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPostStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPreStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPostStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPreStub.java Changeset: d04944441454 Author: Doug Simon Date: 2013-05-14 21:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d04944441454 cleaned up and simplified runtime call mechanisms ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CallingConvention.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledRuntimeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: b2ba1c6f9bf8 Author: Doug Simon Date: 2013-05-14 21:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b2ba1c6f9bf8 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/InitializeArrayNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/InitializeObjectNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TLABAllocateNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java Changeset: a39e67ca883b Author: Morris Meyer Date: 2013-05-14 23:18 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/a39e67ca883b partial SPARC assembler + graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/AbstractSPARCAssembler.java ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCLIRInstruction.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java Changeset: ce80e563cd22 Author: Thomas Wuerthinger Date: 2013-05-14 22:10 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/ce80e563cd22 Remove unused read nodes. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java Changeset: 5797e0028796 Author: Thomas Wuerthinger Date: 2013-05-14 22:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5797e0028796 Fix unused import. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java Changeset: 8cee5c95b774 Author: Christian Haeubl Date: 2013-04-26 12:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8cee5c95b774 fixed documentation for FrameMap.outgoingSize ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java Changeset: 9529ab567367 Author: Christian Haeubl Date: 2013-05-08 16:31 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9529ab567367 Drafted version of an inlining policy that uses the callee graph size as its metric. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Assumptions.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.bytecode/src/com/oracle/graal/bytecode/Bytecodes.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.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.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InlineableElement.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java Changeset: 197426668a5d Author: Christian Haeubl Date: 2013-05-08 17:21 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/197426668a5d Enabled nmethod statistics for the HotSpot product build. ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/java.cpp Changeset: e538498d6eae Author: Christian Haeubl Date: 2013-05-13 13:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e538498d6eae some refactorings and cleanups for the InliningPhase ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 907f1124b427 Author: Christian Haeubl Date: 2013-05-13 13:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/907f1124b427 Removed memory leak and bugfixes for the InliningPhase. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java Changeset: 57113d21ce36 Author: Christian Haeubl Date: 2013-05-13 16:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/57113d21ce36 Added some tunable parameters to the inlining phase. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: f9a65a0e626b Author: Christian Haeubl Date: 2013-05-13 17:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f9a65a0e626b Merge. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ResolvedJavaMethod.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/IdentityHashCodeStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArraySlowStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceSlowStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotSnippetUtils.java - graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/reflect/Reflection_getCallerClass01.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/FrameMap.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/CyclicMaterializeStoreNode.java - graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/nodes/MaterializeObjectNode.java - src/cpu/x86/vm/graalRuntime_x86.cpp - src/cpu/x86/vm/graalStubAssembler_x86.cpp Changeset: de7319e48e48 Author: Christian Haeubl Date: 2013-05-13 17:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/de7319e48e48 Temporary fixes for the merge. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: f44d7e24cebd Author: Christian Haeubl Date: 2013-05-14 10:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f44d7e24cebd Fixes for the merge and inlining cleanups. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: cf0e31151830 Author: Christian Haeubl Date: 2013-05-14 10:18 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cf0e31151830 Merge. - graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotInstalledCodeTest.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompilationResult.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotInstalledCodeExecuteNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotInstalledCodeIntrinsics.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotInstalledCodeSubstitutions.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateNullPointerExceptionStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CreateOutOfBoundsExceptionStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorEnterStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/MonitorExitStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RegisterFinalizerStub.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! src/share/vm/code/nmethod.cpp Changeset: 9530c8b1bd07 Author: Christian Haeubl Date: 2013-05-14 10:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9530c8b1bd07 InliningPhase cleanups. ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java Changeset: 3f647890c067 Author: Christian Haeubl Date: 2013-05-14 11:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3f647890c067 Fix for BoxingEliminationTest. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java Changeset: 19b998ad9264 Author: Christian Haeubl Date: 2013-05-14 15:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/19b998ad9264 Windows-specific idiv/ldiv fix. ! src/os/windows/vm/os_windows.cpp Changeset: 83dcd76c27f1 Author: Christian Haeubl Date: 2013-05-14 16:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/83dcd76c27f1 Merge. - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/InitializeArrayNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/InitializeObjectNode.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TLABAllocateNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: c02f33220973 Author: Christian Haeubl Date: 2013-05-14 17:52 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c02f33220973 Adjusted test-case workaround. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java Changeset: 4420f32a6d5c Author: Christian Haeubl Date: 2013-05-15 09:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4420f32a6d5c Disabled a test-case temporarily. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/BoxingEliminationTest.java Changeset: 521c4f7aac66 Author: Christian Haeubl Date: 2013-05-15 09:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/521c4f7aac66 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPostStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/WriteBarrierPreStub.java Changeset: badabdca0c53 Author: Lukas Stadler Date: 2013-05-15 10:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/badabdca0c53 fix final-ness of @Input node inputs ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CRuntimeCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/TailcallNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/BreakpointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/CallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IndirectCallTargetNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AbstractCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/NullCheckNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ValueAnchorNode.java Changeset: e0b95acd24ae Author: Lukas Stadler Date: 2013-05-15 10:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e0b95acd24ae add check for final-ness and visibility of @Input and @Successor fields to NodeClass ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: f8e0bf2c70e2 Author: Doug Simon Date: 2013-05-14 22:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f8e0bf2c70e2 consolidated the two RegisterConfig instances for HotSpotRuntime into one ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: 6623dda5fabb Author: Doug Simon Date: 2013-05-15 14:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6623dda5fabb Merge. Changeset: f6b1694360ec Author: Doug Simon Date: 2013-05-15 14:56 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f6b1694360ec added links to the HotSpot Windows sources ! hotspot/.project Changeset: d30cc6543973 Author: Lukas Stadler Date: 2013-05-15 17:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d30cc6543973 fix concurrency issue in NodeClass.get ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: 65452ead4b71 Author: Christian Wimmer Date: 2013-05-15 14:30 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/65452ead4b71 Handle corner case in WordTypeVerificationPhase ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeVerificationPhase.java Changeset: b5dd7e3c8c80 Author: Christian Haeubl Date: 2013-05-16 15:16 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b5dd7e3c8c80 Bugfixes for the inlining phase and for -XX:+PrintInlining. ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: e4d8c9b05783 Author: Lukas Stadler Date: 2013-05-16 16:53 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e4d8c9b05783 use only appendConstant for appending constants in GraphBuilderPhase ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 8e8ea20621e7 Author: Lukas Stadler Date: 2013-05-16 17:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8e8ea20621e7 simplify GraphBuilderPhase: append adds the node to the graph ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 222461d02a72 Author: Lukas Stadler Date: 2013-05-16 17:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/222461d02a72 removed killed reads from list in memory aware scheduling ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 8ba0e5cab309 Author: Lukas Stadler Date: 2013-05-16 18:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8ba0e5cab309 fix remaining currentGraph.add in GraphBuilderPhase ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 0dd573144b5b Author: Lukas Stadler Date: 2013-05-16 18:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0dd573144b5b allow only .isAlive() nodes to be added to a FrameStateBuilder ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java Changeset: 2dc020b33a6e Author: Lukas Stadler Date: 2013-05-16 18:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2dc020b33a6e set bootstrapRunning flag earlier (in VMToCompiler.startCompiler) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp Changeset: 4c2c99854535 Author: Lukas Stadler Date: 2013-05-16 18:15 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4c2c99854535 typo in StructuredGraph ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java Changeset: d58ebf85443e Author: Doug Simon Date: 2013-05-15 16:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d58ebf85443e spelling fix ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java Changeset: f7bd4594cbbf Author: Doug Simon Date: 2013-05-15 21:37 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f7bd4594cbbf added support for declaring a foreign function call to be a leaf ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java Changeset: 1a5fbe41b8d4 Author: Doug Simon Date: 2013-05-15 21:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1a5fbe41b8d4 made identityHashCode, javaTimeMillis and javaTimeNanos be CRuntimeCalls instead of RuntimeCallNodes ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemSubstitutions.java Changeset: b88f69f80681 Author: Doug Simon Date: 2013-05-15 22:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b88f69f80681 Merge. Changeset: 1313dd590c62 Author: Doug Simon Date: 2013-05-16 15:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1313dd590c62 made RuntimeCallNode no longer be a StateSplit; for runtime calls that are state splits, the new RuntimeCallStateSplitNode class should be used ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallStateSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/Log.java Changeset: 2e4f035186cf Author: Doug Simon Date: 2013-05-16 16:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2e4f035186cf rename: Descriptor -> ForeignCallDescriptor ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RuntimeCallTarget.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CRuntimeCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPostStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPreStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallStateSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/Log.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java Changeset: 951d5ebf3c49 Author: Doug Simon Date: 2013-05-16 16:17 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/951d5ebf3c49 refactored ForeignCallDescriptor into a top level class and moved it to the api.meta project ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RuntimeCallTarget.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ForeignCallDescriptor.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CRuntimeCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPostStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPreStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallStateSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/Log.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java Changeset: 34c892fdfb6d Author: Doug Simon Date: 2013-05-16 16:32 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/34c892fdfb6d moved responsibility for determining if a foreign call has a side effect to the runtime ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ForeignCallDescriptor.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPostStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPreStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallStateSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/Log.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java Changeset: 857632c8086a Author: Doug Simon Date: 2013-05-16 16:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/857632c8086a renamed: RuntimeCallNode -> ForeignCallNode, RuntimeCallStateSplitNode -> ForeignCallStateSplitNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/phases/LoopSafepointEliminationPhase.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java = graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallStateSplitNode.java < graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallStateSplitNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallNode.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/Log.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java Changeset: 4cd4926ec683 Author: Doug Simon Date: 2013-05-16 17:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4cd4926ec683 rename: RuntimeCallTarget -> ForeignCallLinkage ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CodeCacheProvider.java + graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ForeignCallLinkage.java - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RuntimeCallTarget.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotUnwindOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CRuntimeCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPostStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPreStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Call.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java Changeset: c4b1aa93b9af Author: Doug Simon Date: 2013-05-16 17:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c4b1aa93b9af rename: HotSpotRuntimeCallTarget -> HotSpotForeignCallLinkage ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledRuntimeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java < graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CRuntimeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: b27184f5f66b Author: Doug Simon Date: 2013-05-16 17:36 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b27184f5f66b removed redundant parameter ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CRuntimeCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorExitStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewInstanceStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VMErrorNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPostStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/WriteBarrierPreStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java Changeset: cff1e11941c0 Author: Doug Simon Date: 2013-05-16 18:05 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cff1e11941c0 moved temporaries from CallingConvention to ForeignCallLinkage ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CallingConvention.java ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ForeignCallLinkage.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java Changeset: 590e157cf4d4 Author: Doug Simon Date: 2013-05-16 18:12 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/590e157cf4d4 rename: RuntimeCallStub -> ForeignCallStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java < graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java Changeset: 8342b10b9cc3 Author: Doug Simon Date: 2013-05-16 18:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8342b10b9cc3 rename: *RuntimeCallOp -> *ForeignCallOp ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Call.java Changeset: b9c5ce8d552d Author: Doug Simon Date: 2013-05-16 20:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b9c5ce8d552d ForeignCallNode kills all memory locations ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java Changeset: 82e3c8d5c77f Author: Doug Simon Date: 2013-05-16 20:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/82e3c8d5c77f removed CRuntimeCall and replaced its usages with ForeignCallNode - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CRuntimeCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/StubUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java Changeset: 8e5461c4c82e Author: Doug Simon Date: 2013-05-16 21:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8e5461c4c82e replaced NewMultiArrayStub use of ForeignCallStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java Changeset: 3e049a94d391 Author: Doug Simon Date: 2013-05-16 21:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3e049a94d391 replaced Log*Stub use of ForeignCallStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java Changeset: 5650637a3867 Author: Doug Simon Date: 2013-05-16 21:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5650637a3867 replaced ThreadIsInterruptedStub with use of ForeignCallStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java Changeset: 23a047fba2df Author: Doug Simon Date: 2013-05-16 21:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/23a047fba2df removed redundant methods ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java Changeset: ff9829c21f21 Author: Doug Simon Date: 2013-05-16 22:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ff9829c21f21 replaced OSRMigrationEndStub with use of ForeignCallStub ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java Changeset: 82689c1c0dab Author: Doug Simon Date: 2013-05-16 23:26 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/82689c1c0dab replaced VMErrorStub with use of ForeignCallStub deleted CRuntimeStub added more documentation to ForeignCallStub ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CRuntimeStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ExceptionHandlerStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/SnippetStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/UnwindExceptionToCallerStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java Changeset: 6c2a7fc32416 Author: Doug Simon Date: 2013-05-16 23:30 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6c2a7fc32416 Merge. ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 98b004bf3985 Author: Christian Wimmer Date: 2013-05-16 17:03 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/98b004bf3985 Refactoring of NodeUtil to centralize the use of reflection ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/GraphPrintVisitor.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeUtil.java Changeset: 432b8405e056 Author: Lukas Stadler Date: 2013-05-17 14:29 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/432b8405e056 small refactoring of early read elimination (move logic into "virtualize" methods) ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoadFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/StoreFieldNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/VirtualizableAllocation.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/VirtualizableRoot.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/VirtualizerTool.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: d51f6d7fa6c4 Author: Roland Schatz Date: 2013-05-17 15:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d51f6d7fa6c4 Remove magic number in macro assembler. ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64MacroAssembler.java Changeset: e865310767be Author: Roland Schatz Date: 2013-05-17 13:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e865310767be Method for determining supported vector lengths. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Architecture.java Changeset: 43a94291d239 Author: Roland Schatz Date: 2013-05-17 13:55 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/43a94291d239 Use correct platform kind when loading a value. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java Changeset: 580faa2ee288 Author: Christian Haeubl Date: 2013-05-17 09:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/580faa2ee288 Avoid inlining of graphs with many invokes. ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: c76b43ed5089 Author: Christian Haeubl Date: 2013-05-17 15:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c76b43ed5089 Added infrastructure for recording invoked methods in the profiling information. + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/AbstractJavaProfile.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/AbstractProfiledItem.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/DefaultProfilingInfo.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaMethodProfile.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/JavaTypeProfile.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ProfilingInfo.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ProfilingInfoTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodDataAccessor.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/graalGlobals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/macros.hpp Changeset: b1e4aebbd19e Author: Christian Haeubl Date: 2013-05-17 15:40 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b1e4aebbd19e Merge. - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RuntimeCallTarget.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CRuntimeCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CRuntimeStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallNode.java Changeset: 57e5211846f9 Author: Christian Haeubl Date: 2013-05-17 17:24 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/57e5211846f9 Added class unloading support to the method profiling infrastructure. ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp Changeset: 4a8b9117327a Author: Christian Haeubl Date: 2013-05-17 17:34 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4a8b9117327a Removed MethodProfile testcases. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ProfilingInfoTest.java Changeset: 51545c49083a Author: Christian Haeubl Date: 2013-05-17 17:35 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/51545c49083a Minor refactoring. ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java Changeset: 2461285a2f90 Author: Christian Haeubl Date: 2013-05-17 17:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2461285a2f90 Bugfix. ! src/share/vm/oops/methodData.cpp Changeset: a2074a73aeef Author: Doug Simon Date: 2013-05-17 16:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a2074a73aeef added test for AES intrinsification + graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java Changeset: e415e58e0db2 Author: Doug Simon Date: 2013-05-17 22:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e415e58e0db2 changed location of debug scope so that a subclass that overrides 'addMethod' still matches -G:Dump=CodeInstall option ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotCryptoSubstitutionTest.java Changeset: cbf274a92e5b Author: Doug Simon Date: 2013-05-17 22:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/cbf274a92e5b a leaf foreign call does not need debug info ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java Changeset: 15a696a25108 Author: Doug Simon Date: 2013-05-17 22:04 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/15a696a25108 replaced CryptBlockStubCall (and its subclasses) with usage of ForeignCallNode ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java Changeset: 9a32908912ae Author: Doug Simon Date: 2013-05-17 22:11 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9a32908912ae replaced AESCryptStubCall (and its subclasses) with usage of ForeignCallNode ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java Changeset: 4de03457d5c8 Author: Doug Simon Date: 2013-05-17 22:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4de03457d5c8 replaced MonitorEnterStubCall with usage of ForeignCallNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java Changeset: 9c5078e16fd9 Author: Doug Simon Date: 2013-05-17 22:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9c5078e16fd9 replaced ThreadIsInterruptedStubCall with usage of ForeignCallNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ThreadSubstitutions.java Changeset: 8a1b0a3d4fc3 Author: Doug Simon Date: 2013-05-17 22:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a1b0a3d4fc3 replaced VerifyOopStubCall with usage of ForeignCallNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VerifyOopStub.java Changeset: 20963f52fdd5 Author: Doug Simon Date: 2013-05-17 22:45 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/20963f52fdd5 Merge. From Vasanth.Venkatachalam at amd.com Mon May 20 15:22:23 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Mon, 20 May 2013 22:22:23 +0000 Subject: flags to analyze register spilling issues Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8C8C81@sausexdag06.amd.com> Are there any flags that can be used to analyze why Graal decides it needs to spill registers? We have a small test case which we wouldn't expect would require spilling, and we're investigating why Graal thinks that no registers are available. Vasanth From thomas.wuerthinger at oracle.com Mon May 20 17:19:58 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 21 May 2013 02:19:58 +0200 Subject: RFR (S): use invoker's stamp if target's return stamp is of different type In-Reply-To: References: Message-ID: Looks good - please push! - thomas On May 17, 2013, at 1:00 AM, Christian Thalinger wrote: > This is a fix for 292. > > -- Chris > > diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java > --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java > +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java > @@ -273,9 +273,20 @@ > ValueNode[] args = replacementArguments.toArray(new ValueNode[replacementArguments.size()]); > callTarget = new SelfReplacingMethodCallTargetNode(invokeKind, targetMethod, targetArguments, returnType, replacementTargetMethod, args, replacementReturnType); > } > + graph().add(callTarget); > > - graph().add(callTarget); > - InvokeNode invoke = graph().add(new InvokeNode(callTarget, getBci())); > + // The call target can have a different return type than the invoker, > + // e.g. the target returns an Object but the invoker void. In this case > + // we need to use the stamp of the invoker. Note: always using the > + // invoker's stamp would be wrong because it's a less concrete type > + // (usually java.lang.Object). > + InvokeNode invoke; > + if (callTarget.returnStamp().kind() != stamp().kind()) { > + invoke = new InvokeNode(callTarget, getBci(), stamp()); > + } else { > + invoke = new InvokeNode(callTarget, getBci()); > + } > + graph().add(invoke); > invoke.setStateAfter(stateAfter()); > return invoke; > } > diff --git a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java > --- a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java > +++ b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java > @@ -29,6 +29,7 @@ > import com.oracle.graal.nodes.extended.*; > import com.oracle.graal.nodes.extended.LocationNode.LocationIdentity; > import com.oracle.graal.nodes.spi.*; > +import com.oracle.graal.nodes.type.Stamp; > import com.oracle.graal.nodes.util.*; > > /** > @@ -47,11 +48,22 @@ > /** > * Constructs a new Invoke instruction. > * > + * @param callTarget the target method being called > * @param bci the bytecode index of the original invoke (used for debug infos) > - * @param callTarget the target method being called > */ > public InvokeNode(CallTargetNode callTarget, int bci) { > - super(callTarget.returnStamp()); > + this(callTarget, bci, callTarget.returnStamp()); > + } > + > + /** > + * Constructs a new Invoke instruction. > + * > + * @param callTarget the target method being called > + * @param bci the bytecode index of the original invoke (used for debug infos) > + * @param stamp the stamp to be used for this value > + */ > + public InvokeNode(CallTargetNode callTarget, int bci, Stamp stamp) { > + super(stamp); > this.callTarget = callTarget; > this.bci = bci; > this.polymorphic = false; > From doug.simon at oracle.com Tue May 21 00:07:13 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 21 May 2013 09:07:13 +0200 Subject: flags to analyze register spilling issues In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8C8C81@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8C8C81@sausexdag06.amd.com> Message-ID: There is -G:TraceLinearScanLevel= where level is between 1 and 4. On May 21, 2013, at 12:22 AM, "Venkatachalam, Vasanth" wrote: > Are there any flags that can be used to analyze why Graal decides it needs to spill registers? > > We have a small test case which we wouldn't expect would require spilling, and we're investigating why Graal thinks that no registers are available. > > Vasanth From thomas.wuerthinger at oracle.com Tue May 21 00:50:42 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 21 May 2013 09:50:42 +0200 Subject: flags to analyze register spilling issues In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A73D8C8C81@sausexdag06.amd.com> Message-ID: <3DB166A4-EFCE-4094-8E4F-402D28346BA4@oracle.com> Another option is to use the PrintCFG flag for enabling c1visualizer [1] output. Here is an example command line: ./mx.sh vm -G:+PrintCFG -G:MethodFilter=myMethodName -G:Dump= - thomas [1] https://java.net/projects/c1visualizer/ On May 21, 2013, at 9:07 AM, Doug Simon wrote: > There is -G:TraceLinearScanLevel= where level is between 1 and 4. > > On May 21, 2013, at 12:22 AM, "Venkatachalam, Vasanth" wrote: > >> Are there any flags that can be used to analyze why Graal decides it needs to spill registers? >> >> We have a small test case which we wouldn't expect would require spilling, and we're investigating why Graal thinks that no registers are available. >> >> Vasanth > From Vasanth.Venkatachalam at amd.com Tue May 21 08:43:37 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 21 May 2013 15:43:37 +0000 Subject: BasicAMD64Test Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8C943C@sausexdag06.amd.com> Hi, The below test case for the AMD64 backend used to work, but after a recent merge it now fails with the error: Java.lang.AssertionError: linkage without and address must be a stub - forgot to register a Stub associated with exceptionHandler(Object,Word) void. Can someone explain what we need to do to get this working again? Also is there a way we can get the AMD64 backend to display the disassembled generated code? Also it would be useful if we could write our test cases in one central location and run them in any backend (AMD64, PTX, HSAIL etc) instead of duplicating them into the test directories for each of the backends. BasicAMD64Test.java public class BasicAMD64Test extends GraalCompilerTest { @Test public void testArray2() { test("testArrayVarSnippet"); } public static int testArrayVarSnippet(int[] array, int n) { return array[n]; } private CompilationResult test(String snippet) { StructuredGraph graph = parse(snippet); Debug.dump(graph, "Graph"); TargetDescription target = new TargetDescription(new AMD64(4, 1), true, 1, 0, true); AMD64HotSpotBackend amd64Backend = new AMD64HotSpotBackend(new AMD64HotSpotGraalRuntime().getRuntime(), target); PhasePlan phasePlan = new PhasePlan(); GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); phasePlan.addPhase(PhasePosition.AFTER_PARSING, new AMD64Phase()); new AMD64Phase().apply(graph); CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); CompilationResult result = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, graalRuntime().getReplacements(), amd64Backend, target, null, phasePlan, OptimisticOptimizations.NONE, new SpeculationLog()); DisassemblerProvider dis = Graal.getRuntime().getCapability(DisassemblerProvider.class); /****** * if (dis != null) { String disasm = dis.disassemble(result); } **********/ if (true) { String disasm = new AMD64HotSpotGraalRuntime().getRuntime().disassemble(result, null); System.out.println("code for snippet " + snippet + " " + disasm); } return result; } private static class AMD64Phase extends Phase { @Override protected void run(StructuredGraph graph) { for (LocalNode local : graph.getNodes(LocalNode.class)) { if (local.kind() == Kind.Object) { local.setStamp(StampFactory.declaredNonNull(local.objectStamp().type())); } } } } From Vasanth.Venkatachalam at amd.com Tue May 21 08:47:36 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Tue, 21 May 2013 15:47:36 +0000 Subject: register encodings Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8C945A@sausexdag06.amd.com> Hi, We heard a few months ago that there were plans to extricate the PTX backend from relying on x86 register encodings. We'd be interested in knowing the status of the work, as we're hitting some register spilling issues in our HSAIL backend, which is still getting passed x86 register encodings. Vasanth From doug.simon at oracle.com Tue May 21 09:16:08 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 21 May 2013 18:16:08 +0200 Subject: Foreign calls + Compiled stubs Message-ID: <1BA34F93-1050-4318-B2FE-54C34845B08B@oracle.com> Hi, This is an update on the changes I've pushed over the last 2 weeks. As described in the javadoc for ForeignCallDescriptor, a foreign call differs from a normal compiled Java call in at least one of these aspects: - The call is to C/C++/assembler code. - The call uses different conventions for passing parameters or returning values. - The callee has different register saving semantics. For example, the callee may save all registers (apart from some specified temporaries) in which case the register allocator doesn't not need to spill all live registers around the call site. - The call does not derive from an INVOKE* bytecode. Slow path support routines are also called by foreign calls. These stubs that may handle "medium path" logic directly (e.g., NewInstanceStub implements TLAB refill logic, only calling out to a C++ function if that fails) or simply call out to a runtime function (written in C/C++ or manually assembled). For the latter, stub generation is largely automated through use of the ForeignCallStub. Linking foreign calls is a matter of creating a HotSpotForeignCallLinkage object for each ForeignCallDescriptor. It's probably best to just see how this is done in [AMD64]HotSpotRuntime.registerReplacements(). One enhancement we are considering, is to modify HotSpot such that it can handle calls to normal Java code from non-invoke bytecodes. This would allow one to write certain support routines in Java (such as the routines for creating ArrayIndexOutOfBoundsExceptions and NullPointerExceptions). It would also allow for pretty powerful instrumentation routines to be written in Java where all register and stack values are made available to the support routine (for example). -Doug From doug.simon at oracle.com Tue May 21 09:24:04 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 21 May 2013 18:24:04 +0200 Subject: BasicAMD64Test In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8C943C@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8C943C@sausexdag06.amd.com> Message-ID: <4BDA47B2-4DE4-483B-92A1-FD5E18E2A972@oracle.com> Hi Vasanth, On May 21, 2013, at 5:43 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > The below test case for the AMD64 backend used to work, but after a recent merge it now fails with the error: > > Java.lang.AssertionError: linkage without and address must be a stub - forgot to register a Stub associated with exceptionHandler(Object,Word) void. > > Can someone explain what we need to do to get this working again? Recent changes have removed this assertion. Please let me know if you still get this (or a similar) error after pulling the most recent changes. > Also is there a way we can get the AMD64 backend to display the disassembled generated code? What is not working with the (commented out) disassembler call in your attached code? > Also it would be useful if we could write our test cases in one central location and run them in any backend (AMD64, PTX, HSAIL etc) instead of duplicating them into the test directories for each of the backends. I assume you are talking about non-backend-specific tests. In that case, can't you just create a project similar to com.oracle.graal.compiler.test or com.oracle.graal.hotspot.test? -Doug > BasicAMD64Test.java > > public class BasicAMD64Test extends GraalCompilerTest { > > @Test > public void testArray2() { > test("testArrayVarSnippet"); > } > > public static int testArrayVarSnippet(int[] array, int n) { > return array[n]; > } > > private CompilationResult test(String snippet) { > StructuredGraph graph = parse(snippet); > Debug.dump(graph, "Graph"); > TargetDescription target = new TargetDescription(new AMD64(4, 1), true, 1, 0, true); > AMD64HotSpotBackend amd64Backend = new AMD64HotSpotBackend(new AMD64HotSpotGraalRuntime().getRuntime(), target); > PhasePlan phasePlan = new PhasePlan(); > GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); > phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); > phasePlan.addPhase(PhasePosition.AFTER_PARSING, new AMD64Phase()); > new AMD64Phase().apply(graph); > CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); > CompilationResult result = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, graalRuntime().getReplacements(), amd64Backend, target, null, phasePlan, > OptimisticOptimizations.NONE, new SpeculationLog()); > DisassemblerProvider dis = Graal.getRuntime().getCapability(DisassemblerProvider.class); > /****** > * if (dis != null) { String disasm = dis.disassemble(result); } > **********/ > if (true) { > String disasm = new AMD64HotSpotGraalRuntime().getRuntime().disassemble(result, null); > System.out.println("code for snippet " + snippet + " " + disasm); > } > return result; > } > > private static class AMD64Phase extends Phase { > > @Override > protected void run(StructuredGraph graph) { > for (LocalNode local : graph.getNodes(LocalNode.class)) { > if (local.kind() == Kind.Object) { > local.setStamp(StampFactory.declaredNonNull(local.objectStamp().type())); > } > } > } > > } > From christian.thalinger at oracle.com Tue May 21 17:58:55 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 21 May 2013 17:58:55 -0700 Subject: RFR (S): use invoker's stamp if target's return stamp is of different type In-Reply-To: References: Message-ID: <1909E6EE-BC47-4A5C-8301-0B7AFF9930CF@oracle.com> On May 20, 2013, at 5:19 PM, Thomas Wuerthinger wrote: > Looks good - please push! Thanks. I almost forgot about it. -- Chris > > - thomas > > On May 17, 2013, at 1:00 AM, Christian Thalinger wrote: > >> This is a fix for 292. >> >> -- Chris >> >> diff --git a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java >> --- a/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java >> +++ b/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java >> @@ -273,9 +273,20 @@ >> ValueNode[] args = replacementArguments.toArray(new ValueNode[replacementArguments.size()]); >> callTarget = new SelfReplacingMethodCallTargetNode(invokeKind, targetMethod, targetArguments, returnType, replacementTargetMethod, args, replacementReturnType); >> } >> + graph().add(callTarget); >> >> - graph().add(callTarget); >> - InvokeNode invoke = graph().add(new InvokeNode(callTarget, getBci())); >> + // The call target can have a different return type than the invoker, >> + // e.g. the target returns an Object but the invoker void. In this case >> + // we need to use the stamp of the invoker. Note: always using the >> + // invoker's stamp would be wrong because it's a less concrete type >> + // (usually java.lang.Object). >> + InvokeNode invoke; >> + if (callTarget.returnStamp().kind() != stamp().kind()) { >> + invoke = new InvokeNode(callTarget, getBci(), stamp()); >> + } else { >> + invoke = new InvokeNode(callTarget, getBci()); >> + } >> + graph().add(invoke); >> invoke.setStateAfter(stateAfter()); >> return invoke; >> } >> diff --git a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java >> --- a/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java >> +++ b/graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java >> @@ -29,6 +29,7 @@ >> import com.oracle.graal.nodes.extended.*; >> import com.oracle.graal.nodes.extended.LocationNode.LocationIdentity; >> import com.oracle.graal.nodes.spi.*; >> +import com.oracle.graal.nodes.type.Stamp; >> import com.oracle.graal.nodes.util.*; >> >> /** >> @@ -47,11 +48,22 @@ >> /** >> * Constructs a new Invoke instruction. >> * >> + * @param callTarget the target method being called >> * @param bci the bytecode index of the original invoke (used for debug infos) >> - * @param callTarget the target method being called >> */ >> public InvokeNode(CallTargetNode callTarget, int bci) { >> - super(callTarget.returnStamp()); >> + this(callTarget, bci, callTarget.returnStamp()); >> + } >> + >> + /** >> + * Constructs a new Invoke instruction. >> + * >> + * @param callTarget the target method being called >> + * @param bci the bytecode index of the original invoke (used for debug infos) >> + * @param stamp the stamp to be used for this value >> + */ >> + public InvokeNode(CallTargetNode callTarget, int bci, Stamp stamp) { >> + super(stamp); >> this.callTarget = callTarget; >> this.bci = bci; >> this.polymorphic = false; >> > From Vasanth.Venkatachalam at amd.com Wed May 22 13:37:48 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 22 May 2013 20:37:48 +0000 Subject: BasicAMD64Test In-Reply-To: <4BDA47B2-4DE4-483B-92A1-FD5E18E2A972@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D8C943C@sausexdag06.amd.com> <4BDA47B2-4DE4-483B-92A1-FD5E18E2A972@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8C9ABC@sausexdag06.amd.com> Hi Doug, After pulling the most recent changes, I get a new error for the same test case. I did not see this error before. com.oracle.graal.graph.GraalInternalError: java.lang.NullPointerException at lir instruction: DEOPT action: InvalidateReprofile reason: BoundsCheckException info [bci:0] at com.oracle.graal.lir.LIR.emitOp(LIR.java:172) at com.oracle.graal.lir.LIR.emitBlock(LIR.java:161) at com.oracle.graal.lir.LIR.emitCode(LIR.java:147) at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:248) at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:228) at com.oracle.graal.compiler.GraalCompiler$1$3.run(GraalCompiler.java:88) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167) at com.oracle.graal.debug.Debug.scope(Debug.java:118) at com.oracle.graal.debug.Debug.scope(Debug.java:113) at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:85) at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179) at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167) at com.oracle.graal.debug.Debug.scope(Debug.java:118) at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:69) at com.oracle.graal.compiler.amd64.test.BasicAMD64Test.test(BasicAMD64Test.java:257) at com.oracle.graal.compiler.amd64.test.BasicAMD64Test.testNBody(BasicAMD64Test.java:149) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.junit.runner.JUnitCore.run(JUnitCore.java:157) at org.junit.runner.JUnitCore.run(JUnitCore.java:136) at org.junit.runner.JUnitCore.run(JUnitCore.java:117) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98) at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53) at org.junit.runner.JUnitCore.main(JUnitCore.java:45) Caused by: java.lang.NullPointerException at com.oracle.graal.hotspot.meta.HotSpotRuntime.lookupForeignCall(HotSpotRuntime.java:831) at com.oracle.graal.hotspot.meta.HotSpotRuntime.lookupForeignCall(HotSpotRuntime.java:93) at com.oracle.graal.hotspot.amd64.AMD64DeoptimizeOp.emitCode(AMD64DeoptimizeOp.java:55) at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) at com.oracle.graal.lir.LIR.emitOp(LIR.java:168) ... 48 more -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Tuesday, May 21, 2013 11:24 AM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: BasicAMD64Test Hi Vasanth, On May 21, 2013, at 5:43 PM, "Venkatachalam, Vasanth" wrote: > Hi, > > The below test case for the AMD64 backend used to work, but after a recent merge it now fails with the error: > > Java.lang.AssertionError: linkage without and address must be a stub - forgot to register a Stub associated with exceptionHandler(Object,Word) void. > > Can someone explain what we need to do to get this working again? Recent changes have removed this assertion. Please let me know if you still get this (or a similar) error after pulling the most recent changes. > Also is there a way we can get the AMD64 backend to display the disassembled generated code? What is not working with the (commented out) disassembler call in your attached code? > Also it would be useful if we could write our test cases in one central location and run them in any backend (AMD64, PTX, HSAIL etc) instead of duplicating them into the test directories for each of the backends. I assume you are talking about non-backend-specific tests. In that case, can't you just create a project similar to com.oracle.graal.compiler.test or com.oracle.graal.hotspot.test? -Doug > BasicAMD64Test.java > > public class BasicAMD64Test extends GraalCompilerTest { > > @Test > public void testArray2() { > test("testArrayVarSnippet"); > } > > public static int testArrayVarSnippet(int[] array, int n) { > return array[n]; > } > > private CompilationResult test(String snippet) { > StructuredGraph graph = parse(snippet); > Debug.dump(graph, "Graph"); > TargetDescription target = new TargetDescription(new AMD64(4, 1), true, 1, 0, true); > AMD64HotSpotBackend amd64Backend = new AMD64HotSpotBackend(new AMD64HotSpotGraalRuntime().getRuntime(), target); > PhasePlan phasePlan = new PhasePlan(); > GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); > phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); > phasePlan.addPhase(PhasePosition.AFTER_PARSING, new AMD64Phase()); > new AMD64Phase().apply(graph); > CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); > CompilationResult result = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, graalRuntime().getReplacements(), amd64Backend, target, null, phasePlan, > OptimisticOptimizations.NONE, new SpeculationLog()); > DisassemblerProvider dis = Graal.getRuntime().getCapability(DisassemblerProvider.class); > /****** > * if (dis != null) { String disasm = dis.disassemble(result); } > **********/ > if (true) { > String disasm = new AMD64HotSpotGraalRuntime().getRuntime().disassemble(result, null); > System.out.println("code for snippet " + snippet + " " + disasm); > } > return result; > } > > private static class AMD64Phase extends Phase { > > @Override > protected void run(StructuredGraph graph) { > for (LocalNode local : graph.getNodes(LocalNode.class)) { > if (local.kind() == Kind.Object) { > local.setStamp(StampFactory.declaredNonNull(local.objectStamp().type())); > } > } > } > > } > From doug.simon at oracle.com Wed May 22 14:12:54 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 22 May 2013 23:12:54 +0200 Subject: BasicAMD64Test In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8C9ABC@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8C943C@sausexdag06.amd.com> <4BDA47B2-4DE4-483B-92A1-FD5E18E2A972@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D8C9ABC@sausexdag06.amd.com> Message-ID: <685C8080-D546-4349-B6A5-CADE3DB9E112@oracle.com> Hi Vasanth, I don't understand how this can be happening. The stack trace you provide implies that HotSpotRuntime.registerReplacements() is never called as otherwise the registration (on line 232) of the linkage for UNCOMMON_TRAP should have occurred. How are you running these tests? It doesn't look like you are not using mx because I see that assertions are not enabled. It may help if I could see the source code for BasicAMD64Test.java. -Doug On May 22, 2013, at 10:37 PM, "Venkatachalam, Vasanth" wrote: > Hi Doug, > > After pulling the most recent changes, I get a new error for the same test case. I did not see this error before. > > com.oracle.graal.graph.GraalInternalError: java.lang.NullPointerException > at lir instruction: DEOPT action: InvalidateReprofile reason: BoundsCheckException info [bci:0] > at com.oracle.graal.lir.LIR.emitOp(LIR.java:172) > at com.oracle.graal.lir.LIR.emitBlock(LIR.java:161) > at com.oracle.graal.lir.LIR.emitCode(LIR.java:147) > at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:248) > at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:228) > at com.oracle.graal.compiler.GraalCompiler$1$3.run(GraalCompiler.java:88) > at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179) > at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167) > at com.oracle.graal.debug.Debug.scope(Debug.java:118) > at com.oracle.graal.debug.Debug.scope(Debug.java:113) > at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:85) > at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179) > at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167) > at com.oracle.graal.debug.Debug.scope(Debug.java:118) > at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:69) > at com.oracle.graal.compiler.amd64.test.BasicAMD64Test.test(BasicAMD64Test.java:257) > at com.oracle.graal.compiler.amd64.test.BasicAMD64Test.testNBody(BasicAMD64Test.java:149) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at org.junit.runner.JUnitCore.run(JUnitCore.java:136) > at org.junit.runner.JUnitCore.run(JUnitCore.java:117) > at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98) > at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53) > at org.junit.runner.JUnitCore.main(JUnitCore.java:45) > Caused by: java.lang.NullPointerException > at com.oracle.graal.hotspot.meta.HotSpotRuntime.lookupForeignCall(HotSpotRuntime.java:831) > at com.oracle.graal.hotspot.meta.HotSpotRuntime.lookupForeignCall(HotSpotRuntime.java:93) > at com.oracle.graal.hotspot.amd64.AMD64DeoptimizeOp.emitCode(AMD64DeoptimizeOp.java:55) > at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) > at com.oracle.graal.lir.LIR.emitOp(LIR.java:168) > ... 48 more > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, May 21, 2013 11:24 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: BasicAMD64Test > > Hi Vasanth, > > On May 21, 2013, at 5:43 PM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> The below test case for the AMD64 backend used to work, but after a recent merge it now fails with the error: >> >> Java.lang.AssertionError: linkage without and address must be a stub - forgot to register a Stub associated with exceptionHandler(Object,Word) void. >> >> Can someone explain what we need to do to get this working again? > > Recent changes have removed this assertion. Please let me know if you still get this (or a similar) error after pulling the most recent changes. > >> Also is there a way we can get the AMD64 backend to display the disassembled generated code? > > What is not working with the (commented out) disassembler call in your attached code? > >> Also it would be useful if we could write our test cases in one central location and run them in any backend (AMD64, PTX, HSAIL etc) instead of duplicating them into the test directories for each of the backends. > > I assume you are talking about non-backend-specific tests. In that case, can't you just create a project similar to com.oracle.graal.compiler.test or com.oracle.graal.hotspot.test? > > -Doug > >> BasicAMD64Test.java >> >> public class BasicAMD64Test extends GraalCompilerTest { >> >> @Test >> public void testArray2() { >> test("testArrayVarSnippet"); >> } >> >> public static int testArrayVarSnippet(int[] array, int n) { >> return array[n]; >> } >> >> private CompilationResult test(String snippet) { >> StructuredGraph graph = parse(snippet); >> Debug.dump(graph, "Graph"); >> TargetDescription target = new TargetDescription(new AMD64(4, 1), true, 1, 0, true); >> AMD64HotSpotBackend amd64Backend = new AMD64HotSpotBackend(new AMD64HotSpotGraalRuntime().getRuntime(), target); >> PhasePlan phasePlan = new PhasePlan(); >> GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); >> phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); >> phasePlan.addPhase(PhasePosition.AFTER_PARSING, new AMD64Phase()); >> new AMD64Phase().apply(graph); >> CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); >> CompilationResult result = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, graalRuntime().getReplacements(), amd64Backend, target, null, phasePlan, >> OptimisticOptimizations.NONE, new SpeculationLog()); >> DisassemblerProvider dis = Graal.getRuntime().getCapability(DisassemblerProvider.class); >> /****** >> * if (dis != null) { String disasm = dis.disassemble(result); } >> **********/ >> if (true) { >> String disasm = new AMD64HotSpotGraalRuntime().getRuntime().disassemble(result, null); >> System.out.println("code for snippet " + snippet + " " + disasm); >> } >> return result; >> } >> >> private static class AMD64Phase extends Phase { >> >> @Override >> protected void run(StructuredGraph graph) { >> for (LocalNode local : graph.getNodes(LocalNode.class)) { >> if (local.kind() == Kind.Object) { >> local.setStamp(StampFactory.declaredNonNull(local.objectStamp().type())); >> } >> } >> } >> >> } >> > > > From Vasanth.Venkatachalam at amd.com Wed May 22 14:20:28 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 22 May 2013 21:20:28 +0000 Subject: BasicAMD64Test In-Reply-To: <685C8080-D546-4349-B6A5-CADE3DB9E112@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A73D8C943C@sausexdag06.amd.com> <4BDA47B2-4DE4-483B-92A1-FD5E18E2A972@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D8C9ABC@sausexdag06.amd.com> <685C8080-D546-4349-B6A5-CADE3DB9E112@oracle.com> Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8C9B11@sausexdag06.amd.com> Hi Doug, Below is what I have in BasicAMD64Test.java. The testArray2 example is failing with the error I described. package com.oracle.graal.compiler.amd64.test; import org.junit.*; import static com.oracle.graal.api.code.CodeUtil.*; import static com.oracle.graal.hotspot.HotSpotGraalRuntime.*; import com.oracle.graal.api.code.*; import com.oracle.graal.api.meta.*; import com.oracle.graal.api.runtime.*; import com.oracle.graal.compiler.*; import com.oracle.graal.compiler.amd64.*; import com.oracle.graal.compiler.test.*; import com.oracle.graal.debug.*; import com.oracle.graal.java.*; import com.oracle.graal.nodes.*; import com.oracle.graal.nodes.type.*; import com.oracle.graal.phases.*; import com.oracle.graal.phases.PhasePlan.*; import com.oracle.graal.amd64.*; import com.oracle.graal.hotspot.amd64.*; import com.oracle.graal.api.code.CallingConvention.*; import com.oracle.graal.api.runtime.Graal; import com.oracle.graal.compiler.GraalCompiler; import com.oracle.graal.compiler.test.GraalCompilerTest; import com.oracle.graal.java.GraphBuilderConfiguration; import com.oracle.graal.java.GraphBuilderPhase; import com.oracle.graal.nodes.StructuredGraph; import com.oracle.graal.nodes.spi.*; import com.oracle.graal.phases.OptimisticOptimizations; import com.oracle.graal.phases.PhasePlan; import com.oracle.graal.phases.PhasePlan.PhasePosition; /** * Test class for small Java methods compiled to AMD64 kernels. */ public class BasicAMD64Test extends GraalCompilerTest { @Test public void testArray2() { test("testArrayVarSnippet"); } public static int testArrayVarSnippet(int[] array, int n) { return array[n]; } private CompilationResult test(String snippet) { StructuredGraph graph = parse(snippet); Debug.dump(graph, "Graph"); TargetDescription target = new TargetDescription(new AMD64(4, 1), true, 1, 0, true); AMD64HotSpotBackend amd64Backend = new AMD64HotSpotBackend(new AMD64HotSpotGraalRuntime().getRuntime(), target); PhasePlan phasePlan = new PhasePlan(); GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); phasePlan.addPhase(PhasePosition.AFTER_PARSING, new AMD64Phase()); new AMD64Phase().apply(graph); CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); CompilationResult result = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, graalRuntime().getReplacements(), amd64Backend, target, null, phasePlan, OptimisticOptimizations.NONE, new SpeculationLog()); DisassemblerProvider dis = Graal.getRuntime().getCapability(DisassemblerProvider.class); /****** * if (dis != null) { String disasm = dis.disassemble(result); } **********/ if (true) { String disasm = new AMD64HotSpotGraalRuntime().getRuntime().disassemble(result, null); System.out.println("code for snippet " + snippet + " " + disasm); } return result; } private static class AMD64Phase extends Phase { @Override protected void run(StructuredGraph graph) { for (LocalNode local : graph.getNodes(LocalNode.class)) { if (local.kind() == Kind.Object) { local.setStamp(StampFactory.declaredNonNull(local.objectStamp().type())); } } } } } -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Wednesday, May 22, 2013 4:13 PM To: Venkatachalam, Vasanth Cc: graal-dev at openjdk.java.net Subject: Re: BasicAMD64Test Hi Vasanth, I don't understand how this can be happening. The stack trace you provide implies that HotSpotRuntime.registerReplacements() is never called as otherwise the registration (on line 232) of the linkage for UNCOMMON_TRAP should have occurred. How are you running these tests? It doesn't look like you are not using mx because I see that assertions are not enabled. It may help if I could see the source code for BasicAMD64Test.java. -Doug On May 22, 2013, at 10:37 PM, "Venkatachalam, Vasanth" wrote: > Hi Doug, > > After pulling the most recent changes, I get a new error for the same test case. I did not see this error before. > > com.oracle.graal.graph.GraalInternalError: java.lang.NullPointerException > at lir instruction: DEOPT action: InvalidateReprofile reason: BoundsCheckException info [bci:0] > at com.oracle.graal.lir.LIR.emitOp(LIR.java:172) > at com.oracle.graal.lir.LIR.emitBlock(LIR.java:161) > at com.oracle.graal.lir.LIR.emitCode(LIR.java:147) > at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:248) > at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:228) > at com.oracle.graal.compiler.GraalCompiler$1$3.run(GraalCompiler.java:88) > at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179) > at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167) > at com.oracle.graal.debug.Debug.scope(Debug.java:118) > at com.oracle.graal.debug.Debug.scope(Debug.java:113) > at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:85) > at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179) > at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167) > at com.oracle.graal.debug.Debug.scope(Debug.java:118) > at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:69) > at com.oracle.graal.compiler.amd64.test.BasicAMD64Test.test(BasicAMD64Test.java:257) > at com.oracle.graal.compiler.amd64.test.BasicAMD64Test.testNBody(BasicAMD64Test.java:149) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at org.junit.runner.JUnitCore.run(JUnitCore.java:136) > at org.junit.runner.JUnitCore.run(JUnitCore.java:117) > at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98) > at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53) > at org.junit.runner.JUnitCore.main(JUnitCore.java:45) > Caused by: java.lang.NullPointerException > at com.oracle.graal.hotspot.meta.HotSpotRuntime.lookupForeignCall(HotSpotRuntime.java:831) > at com.oracle.graal.hotspot.meta.HotSpotRuntime.lookupForeignCall(HotSpotRuntime.java:93) > at com.oracle.graal.hotspot.amd64.AMD64DeoptimizeOp.emitCode(AMD64DeoptimizeOp.java:55) > at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) > at com.oracle.graal.lir.LIR.emitOp(LIR.java:168) > ... 48 more > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Tuesday, May 21, 2013 11:24 AM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: BasicAMD64Test > > Hi Vasanth, > > On May 21, 2013, at 5:43 PM, "Venkatachalam, Vasanth" wrote: > >> Hi, >> >> The below test case for the AMD64 backend used to work, but after a recent merge it now fails with the error: >> >> Java.lang.AssertionError: linkage without and address must be a stub - forgot to register a Stub associated with exceptionHandler(Object,Word) void. >> >> Can someone explain what we need to do to get this working again? > > Recent changes have removed this assertion. Please let me know if you still get this (or a similar) error after pulling the most recent changes. > >> Also is there a way we can get the AMD64 backend to display the disassembled generated code? > > What is not working with the (commented out) disassembler call in your attached code? > >> Also it would be useful if we could write our test cases in one central location and run them in any backend (AMD64, PTX, HSAIL etc) instead of duplicating them into the test directories for each of the backends. > > I assume you are talking about non-backend-specific tests. In that case, can't you just create a project similar to com.oracle.graal.compiler.test or com.oracle.graal.hotspot.test? > > -Doug > >> BasicAMD64Test.java >> >> public class BasicAMD64Test extends GraalCompilerTest { >> >> @Test >> public void testArray2() { >> test("testArrayVarSnippet"); >> } >> >> public static int testArrayVarSnippet(int[] array, int n) { >> return array[n]; >> } >> >> private CompilationResult test(String snippet) { >> StructuredGraph graph = parse(snippet); >> Debug.dump(graph, "Graph"); >> TargetDescription target = new TargetDescription(new AMD64(4, 1), true, 1, 0, true); >> AMD64HotSpotBackend amd64Backend = new AMD64HotSpotBackend(new AMD64HotSpotGraalRuntime().getRuntime(), target); >> PhasePlan phasePlan = new PhasePlan(); >> GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); >> phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); >> phasePlan.addPhase(PhasePosition.AFTER_PARSING, new AMD64Phase()); >> new AMD64Phase().apply(graph); >> CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); >> CompilationResult result = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, graalRuntime().getReplacements(), amd64Backend, target, null, phasePlan, >> OptimisticOptimizations.NONE, new SpeculationLog()); >> DisassemblerProvider dis = Graal.getRuntime().getCapability(DisassemblerProvider.class); >> /****** >> * if (dis != null) { String disasm = dis.disassemble(result); } >> **********/ >> if (true) { >> String disasm = new AMD64HotSpotGraalRuntime().getRuntime().disassemble(result, null); >> System.out.println("code for snippet " + snippet + " " + disasm); >> } >> return result; >> } >> >> private static class AMD64Phase extends Phase { >> >> @Override >> protected void run(StructuredGraph graph) { >> for (LocalNode local : graph.getNodes(LocalNode.class)) { >> if (local.kind() == Kind.Object) { >> local.setStamp(StampFactory.declaredNonNull(local.objectStamp().type())); >> } >> } >> } >> >> } >> > > > From doug.simon at oracle.com Wed May 22 15:12:09 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 23 May 2013 00:12:09 +0200 Subject: BasicAMD64Test In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8C9B11@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8C943C@sausexdag06.amd.com> <4BDA47B2-4DE4-483B-92A1-FD5E18E2A972@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D8C9ABC@sausexdag06.amd.com> <685C8080-D546-4349-B6A5-CADE3DB9E112@oracle.com> <5DD1503F815BD14889DC81D28643E3A73D8C9B11@sausexdag06.amd.com> Message-ID: There is nothing particularly specific to AMD64 in your test as far as I can see. Also, you should never explicitly create AMD64HotSpotGraalRuntime objects. That is done by the C++ part of Graal during VM bootstrap. I have reworked your test into what I think you ideally want. Place the attached file in graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test and run the following commands to see it in action: mx build mx unittest BasicTest To run it in hosted mode: mx --vm server build mx --vm server unittest BasicTest You should get output like this: executing junit test now... (com.oracle.graal.compiler.test.BasicTest) JUnit version 4.8 .Loaded disassembler from /Users/dsimon/linz/basic-graal/jdk1.7.0_17/product/jre/lib/hsdis-amd64.dylib code generated for testArrayVarSnippet ---------------------------------------------------------------------- com/oracle/graal/compiler/test/BasicTest.testArrayVarSnippet [0x00000001100cbde0, 0x00000001100cbe28] 576 bytes [Disassembling for mach='i386:x86-64'] [Entry Point] [Verified Entry Point] [Constants] # {method} {0x000000010fd13060} 'testArrayVarSnippet' '([II)I' in 'com/oracle/graal/compiler/test/BasicTest' # parm0: rsi:rsi = '[I' # parm1: rdx = int # [sp+0x20] (sp of caller) 0x00000001100cbde0: mov %rax,-0x14000(%rsp) 0x00000001100cbde8: sub $0x18,%rsp 0x00000001100cbdec: mov %rbp,0x10(%rsp) ; OopMap{rsi=Oop off=17} ;*aload_0 ; - com.oracle.graal.compiler.test.BasicTest::testArrayVarSnippet at 0 (line 47) 0x00000001100cbdf1: movslq 0x10(%rsi),%rax 0x00000001100cbdf5: cmp %edx,%eax 0x00000001100cbdf7: jbe 0x00000001100cbe0c 0x00000001100cbdfd: movslq 0x18(%rsi,%rdx,4),%rax 0x00000001100cbe02: mov 0x10(%rsp),%rbp 0x00000001100cbe07: add $0x18,%rsp 0x00000001100cbe0b: retq 0x00000001100cbe0c: movl $0xffffffe5,0x8(%r15) 0x00000001100cbe14: callq 0x000000010ffdddf3 ; OopMap{rsi=Oop off=57} ;*aload_0 ; - com.oracle.graal.compiler.test.BasicTest::testArrayVarSnippet at 0 (line 47 Time: 0.565 OK (1 test) -Doug -------------- next part -------------- On May 22, 2013, at 11:20 PM, "Venkatachalam, Vasanth" wrote: > Hi Doug, > > Below is what I have in BasicAMD64Test.java. The testArray2 example is failing with the error I described. > > package com.oracle.graal.compiler.amd64.test; > > import org.junit.*; > > import static com.oracle.graal.api.code.CodeUtil.*; > import static com.oracle.graal.hotspot.HotSpotGraalRuntime.*; > > import com.oracle.graal.api.code.*; > import com.oracle.graal.api.meta.*; > import com.oracle.graal.api.runtime.*; > import com.oracle.graal.compiler.*; > import com.oracle.graal.compiler.amd64.*; > import com.oracle.graal.compiler.test.*; > import com.oracle.graal.debug.*; > import com.oracle.graal.java.*; > import com.oracle.graal.nodes.*; > import com.oracle.graal.nodes.type.*; > import com.oracle.graal.phases.*; > import com.oracle.graal.phases.PhasePlan.*; > import com.oracle.graal.amd64.*; > import com.oracle.graal.hotspot.amd64.*; > > import com.oracle.graal.api.code.CallingConvention.*; > import com.oracle.graal.api.runtime.Graal; > import com.oracle.graal.compiler.GraalCompiler; > import com.oracle.graal.compiler.test.GraalCompilerTest; > import com.oracle.graal.java.GraphBuilderConfiguration; > import com.oracle.graal.java.GraphBuilderPhase; > import com.oracle.graal.nodes.StructuredGraph; > import com.oracle.graal.nodes.spi.*; > import com.oracle.graal.phases.OptimisticOptimizations; > import com.oracle.graal.phases.PhasePlan; > import com.oracle.graal.phases.PhasePlan.PhasePosition; > > /** > * Test class for small Java methods compiled to AMD64 kernels. > */ > public class BasicAMD64Test extends GraalCompilerTest { > > > > @Test > public void testArray2() { > test("testArrayVarSnippet"); > } > > > public static int testArrayVarSnippet(int[] array, int n) { > return array[n]; > } > > private CompilationResult test(String snippet) { > StructuredGraph graph = parse(snippet); > Debug.dump(graph, "Graph"); > TargetDescription target = new TargetDescription(new AMD64(4, 1), true, 1, 0, true); > AMD64HotSpotBackend amd64Backend = new AMD64HotSpotBackend(new AMD64HotSpotGraalRuntime().getRuntime(), target); > PhasePlan phasePlan = new PhasePlan(); > GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); > phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); > > phasePlan.addPhase(PhasePosition.AFTER_PARSING, new AMD64Phase()); > new AMD64Phase().apply(graph); > CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); > CompilationResult result = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, graalRuntime().getReplacements(), amd64Backend, target, null, phasePlan, > OptimisticOptimizations.NONE, new SpeculationLog()); > > DisassemblerProvider dis = Graal.getRuntime().getCapability(DisassemblerProvider.class); > /****** > * if (dis != null) { String disasm = dis.disassemble(result); } > **********/ > if (true) { > String disasm = new AMD64HotSpotGraalRuntime().getRuntime().disassemble(result, null); > System.out.println("code for snippet " + snippet + " " + disasm); > } > return result; > } > > private static class AMD64Phase extends Phase { > > @Override > protected void run(StructuredGraph graph) { > for (LocalNode local : graph.getNodes(LocalNode.class)) { > if (local.kind() == Kind.Object) { > local.setStamp(StampFactory.declaredNonNull(local.objectStamp().type())); > } > } > } > > } > > } > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, May 22, 2013 4:13 PM > To: Venkatachalam, Vasanth > Cc: graal-dev at openjdk.java.net > Subject: Re: BasicAMD64Test > > Hi Vasanth, > > I don't understand how this can be happening. The stack trace you provide implies that HotSpotRuntime.registerReplacements() is never called as otherwise the registration (on line 232) of the linkage for UNCOMMON_TRAP should have occurred. > > How are you running these tests? It doesn't look like you are not using mx because I see that assertions are not enabled. > > It may help if I could see the source code for BasicAMD64Test.java. > > -Doug > > On May 22, 2013, at 10:37 PM, "Venkatachalam, Vasanth" wrote: > >> Hi Doug, >> >> After pulling the most recent changes, I get a new error for the same test case. I did not see this error before. >> >> com.oracle.graal.graph.GraalInternalError: java.lang.NullPointerException >> at lir instruction: DEOPT action: InvalidateReprofile reason: BoundsCheckException info [bci:0] >> at com.oracle.graal.lir.LIR.emitOp(LIR.java:172) >> at com.oracle.graal.lir.LIR.emitBlock(LIR.java:161) >> at com.oracle.graal.lir.LIR.emitCode(LIR.java:147) >> at com.oracle.graal.hotspot.amd64.AMD64HotSpotBackend.emitCode(AMD64HotSpotBackend.java:248) >> at com.oracle.graal.compiler.GraalCompiler.emitCode(GraalCompiler.java:228) >> at com.oracle.graal.compiler.GraalCompiler$1$3.run(GraalCompiler.java:88) >> at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179) >> at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167) >> at com.oracle.graal.debug.Debug.scope(Debug.java:118) >> at com.oracle.graal.debug.Debug.scope(Debug.java:113) >> at com.oracle.graal.compiler.GraalCompiler$1.run(GraalCompiler.java:85) >> at com.oracle.graal.debug.internal.DebugScope.executeScope(DebugScope.java:179) >> at com.oracle.graal.debug.internal.DebugScope.scope(DebugScope.java:167) >> at com.oracle.graal.debug.Debug.scope(Debug.java:118) >> at com.oracle.graal.compiler.GraalCompiler.compileGraph(GraalCompiler.java:69) >> at com.oracle.graal.compiler.amd64.test.BasicAMD64Test.test(BasicAMD64Test.java:257) >> at com.oracle.graal.compiler.amd64.test.BasicAMD64Test.testNBody(BasicAMD64Test.java:149) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:601) >> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) >> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) >> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) >> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) >> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:300) >> at org.junit.runners.Suite.runChild(Suite.java:128) >> at org.junit.runners.Suite.runChild(Suite.java:24) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:300) >> at org.junit.runner.JUnitCore.run(JUnitCore.java:157) >> at org.junit.runner.JUnitCore.run(JUnitCore.java:136) >> at org.junit.runner.JUnitCore.run(JUnitCore.java:117) >> at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98) >> at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53) >> at org.junit.runner.JUnitCore.main(JUnitCore.java:45) >> Caused by: java.lang.NullPointerException >> at com.oracle.graal.hotspot.meta.HotSpotRuntime.lookupForeignCall(HotSpotRuntime.java:831) >> at com.oracle.graal.hotspot.meta.HotSpotRuntime.lookupForeignCall(HotSpotRuntime.java:93) >> at com.oracle.graal.hotspot.amd64.AMD64DeoptimizeOp.emitCode(AMD64DeoptimizeOp.java:55) >> at com.oracle.graal.lir.amd64.AMD64LIRInstruction.emitCode(AMD64LIRInstruction.java:36) >> at com.oracle.graal.lir.LIR.emitOp(LIR.java:168) >> ... 48 more >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Tuesday, May 21, 2013 11:24 AM >> To: Venkatachalam, Vasanth >> Cc: graal-dev at openjdk.java.net >> Subject: Re: BasicAMD64Test >> >> Hi Vasanth, >> >> On May 21, 2013, at 5:43 PM, "Venkatachalam, Vasanth" wrote: >> >>> Hi, >>> >>> The below test case for the AMD64 backend used to work, but after a recent merge it now fails with the error: >>> >>> Java.lang.AssertionError: linkage without and address must be a stub - forgot to register a Stub associated with exceptionHandler(Object,Word) void. >>> >>> Can someone explain what we need to do to get this working again? >> >> Recent changes have removed this assertion. Please let me know if you still get this (or a similar) error after pulling the most recent changes. >> >>> Also is there a way we can get the AMD64 backend to display the disassembled generated code? >> >> What is not working with the (commented out) disassembler call in your attached code? >> >>> Also it would be useful if we could write our test cases in one central location and run them in any backend (AMD64, PTX, HSAIL etc) instead of duplicating them into the test directories for each of the backends. >> >> I assume you are talking about non-backend-specific tests. In that case, can't you just create a project similar to com.oracle.graal.compiler.test or com.oracle.graal.hotspot.test? >> >> -Doug >> >>> BasicAMD64Test.java >>> >>> public class BasicAMD64Test extends GraalCompilerTest { >>> >>> @Test >>> public void testArray2() { >>> test("testArrayVarSnippet"); >>> } >>> >>> public static int testArrayVarSnippet(int[] array, int n) { >>> return array[n]; >>> } >>> >>> private CompilationResult test(String snippet) { >>> StructuredGraph graph = parse(snippet); >>> Debug.dump(graph, "Graph"); >>> TargetDescription target = new TargetDescription(new AMD64(4, 1), true, 1, 0, true); >>> AMD64HotSpotBackend amd64Backend = new AMD64HotSpotBackend(new AMD64HotSpotGraalRuntime().getRuntime(), target); >>> PhasePlan phasePlan = new PhasePlan(); >>> GraphBuilderPhase graphBuilderPhase = new GraphBuilderPhase(runtime, GraphBuilderConfiguration.getDefault(), OptimisticOptimizations.NONE); >>> phasePlan.addPhase(PhasePosition.AFTER_PARSING, graphBuilderPhase); >>> phasePlan.addPhase(PhasePosition.AFTER_PARSING, new AMD64Phase()); >>> new AMD64Phase().apply(graph); >>> CallingConvention cc = getCallingConvention(runtime, Type.JavaCallee, graph.method(), false); >>> CompilationResult result = GraalCompiler.compileGraph(graph, cc, graph.method(), runtime, graalRuntime().getReplacements(), amd64Backend, target, null, phasePlan, >>> OptimisticOptimizations.NONE, new SpeculationLog()); >>> DisassemblerProvider dis = Graal.getRuntime().getCapability(DisassemblerProvider.class); >>> /****** >>> * if (dis != null) { String disasm = dis.disassemble(result); } >>> **********/ >>> if (true) { >>> String disasm = new AMD64HotSpotGraalRuntime().getRuntime().disassemble(result, null); >>> System.out.println("code for snippet " + snippet + " " + disasm); >>> } >>> return result; >>> } >>> >>> private static class AMD64Phase extends Phase { >>> >>> @Override >>> protected void run(StructuredGraph graph) { >>> for (LocalNode local : graph.getNodes(LocalNode.class)) { >>> if (local.kind() == Kind.Object) { >>> local.setStamp(StampFactory.declaredNonNull(local.objectStamp().type())); >>> } >>> } >>> } >>> >>> } >>> >> >> >> > > > From tom.deneau at amd.com Thu May 23 09:55:58 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 23 May 2013 16:55:58 +0000 Subject: annotating generated code with source and bytecode info Message-ID: We would like to be able to annotate our HSAIL code generation (using comments) to get something like the annotations that are seen in the AMD64 disassembly. (as shown below) Can you point me to where in the code to look to generate such comments? -- Tom Deneau 0x00007f70bfb7b49c: mov qword ptr [rsp+0x10],rbp ; OopMap{rsi=Oop off=17} ;*aload_0 ; - com.oracle.graal.compiler.test.BasicTest::testArrayVarSnippet at 0 (line 22) From doug.simon at oracle.com Thu May 23 14:41:19 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 23 May 2013 23:41:19 +0200 Subject: annotating generated code with source and bytecode info In-Reply-To: References: Message-ID: Hi Tom, On May 23, 2013, at 6:55 PM, "Deneau, Tom" wrote: > > We would like to be able to annotate our HSAIL code generation (using comments) > to get something like the annotations that are seen in the AMD64 disassembly. (as shown below) The comments in your example are automatically generated by HotSpot's disassembler. I'm am making a push right now that connects comments added via TargetMethodAssembler.blockComment() to the output of the disassembler. Once you have pulled changeset d552919fbb05 (which should be in the OpenJDK repo within the next hour) you can see it in action as follows (code comments are only supported in non-product builds): % mx build fastdebug % mx --fastdebug vm -XX:CompileCommand=print,*Object.toString The line " ;; [stack overflow check]" comment in the output is produced by AMD64HotSpotBackend.java:90: tasm.blockComment("[stack overflow check]"); -Doug From christian.thalinger at oracle.com Thu May 23 15:26:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 May 2013 15:26:20 -0700 Subject: annotating generated code with source and bytecode info In-Reply-To: References: Message-ID: <85B11B81-76D9-4F6B-94B7-93C0797F1FC0@oracle.com> On May 23, 2013, at 2:41 PM, Doug Simon wrote: > Hi Tom, > > On May 23, 2013, at 6:55 PM, "Deneau, Tom" wrote: > >> >> We would like to be able to annotate our HSAIL code generation (using comments) >> to get something like the annotations that are seen in the AMD64 disassembly. (as shown below) > > The comments in your example are automatically generated by HotSpot's disassembler. > > I'm am making a push right now that connects comments added via TargetMethodAssembler.blockComment() to the output of the disassembler. Once you have pulled changeset d552919fbb05 (which should be in the OpenJDK repo within the next hour) you can see it in action as follows (code comments are only supported in non-product builds): > > % mx build fastdebug > % mx --fastdebug vm -XX:CompileCommand=print,*Object.toString > > The line " ;; [stack overflow check]" comment in the output is produced by AMD64HotSpotBackend.java:90: > > tasm.blockComment("[stack overflow check]"); This is great. Thanks for doing this. -- Chris > > -Doug From doug.simon at oracle.com Thu May 23 16:01:37 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Thu, 23 May 2013 23:01:37 +0000 Subject: hg: graal/graal: 33 new changesets Message-ID: <20130523230329.9D7C948CC4@hg.openjdk.java.net> Changeset: 5dc05fdcf3c2 Author: Chris Seaton Date: 2013-05-20 23:22 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/5dc05fdcf3c2 Fix SourceSection.getCode. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/SourceSection.java Changeset: f43313f3f759 Author: Doug Simon Date: 2013-05-21 11:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/f43313f3f759 put error details into exception instead of printing to the console ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRVerifier.java Changeset: 05b719a4ae09 Author: Doug Simon Date: 2013-05-21 12:39 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/05b719a4ae09 expanded documentation for ForeignCallDescriptor ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ForeignCallDescriptor.java Changeset: 7421f2894cfc Author: Christian Humer Date: 2013-05-21 19:19 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7421f2894cfc Added kind field to NodeInfo annotation. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeInfo.java Changeset: 0e4db5ee0695 Author: Christian Humer Date: 2013-05-21 19:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/0e4db5ee0695 Added support for the kind field in @NodeInfo for the source code generation. ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/TruffleTypes.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/Utils.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeAnnotationMirror.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeData.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeParser.java Changeset: 763100239da6 Author: Christian Humer Date: 2013-05-21 19:20 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/763100239da6 Fixed GRAAL-276. ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/ExecutableTypeData.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/ExecutableTypeMethodParser.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/template/ParameterSpec.java Changeset: c15fd053efb6 Author: Christian Humer Date: 2013-05-21 19:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c15fd053efb6 Fixed typo in NodeInfo.Kind. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/NodeInfo.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeCodeGenerator.java Changeset: ba02d19dd3cc Author: Christian Humer Date: 2013-05-21 19:43 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ba02d19dd3cc Added an onReplace method to Node to provide a way for a guest language implementation to use replace tracing. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/Node.java Changeset: 5402504894fe Author: Christian Humer Date: 2013-05-21 19:51 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/5402504894fe Merge. - graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/RuntimeCallTarget.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotRuntimeCallTarget.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/CRuntimeCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/CRuntimeStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogObjectStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrimitiveStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/LogPrintfStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewMultiArrayStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/OSRMigrationEndStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/RuntimeCallStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ThreadIsInterruptedStub.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/VMErrorStub.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/RuntimeCallNode.java Changeset: 747b2517feae Author: twisti Date: 2013-05-21 17:56 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/747b2517feae use invoker's stamp if target's return stamp is of different type ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AbstractMethodHandleNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java Changeset: ecd5cd2806e8 Author: Thomas Wuerthinger Date: 2013-05-22 14:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ecd5cd2806e8 Relax assertion for virtual array component kind. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/VirtualObject.java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/Kind.java Changeset: 6c1f7b853d35 Author: Thomas Wuerthinger Date: 2013-05-22 14:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6c1f7b853d35 Generalize the code for detecting invalid stamps in join operations. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CheckCastNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/type/ObjectStamp.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningPhase.java Changeset: 3207fae2e2f6 Author: Bernhard Urban Date: 2013-05-21 18:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/3207fae2e2f6 Value: do equals test of `name' as assertion ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/Register.java Changeset: 1bd67c5bdab8 Author: Bernhard Urban Date: 2013-05-21 18:03 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1bd67c5bdab8 VerifyUsageWithEquals: allow to pass a class to the phase and add Register-class as a phase ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java - graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyValueUsage.java Changeset: ad50389f1da4 Author: Bernhard Urban Date: 2013-05-22 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/ad50389f1da4 VerifyUsageWithEquals: refactoring ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java Changeset: 6b515c453646 Author: Bernhard Urban Date: 2013-05-22 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/6b515c453646 CompilationTask: print exception of compilation also when we don't exit the VM for example, this is useful for CTW, in order to see on which methods the compiler bails out ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java Changeset: e92fdf3e1558 Author: Bernhard Urban Date: 2013-05-22 16:28 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/e92fdf3e1558 Register: replace usages of object identity with equals() ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ValueUtil.java ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Address.java ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotEpilogueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64IndirectCallOp.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/AMD64ControlFlow.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 06dc2d2324d6 Author: Doug Simon Date: 2013-05-21 21:46 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/06dc2d2324d6 pulled LocationIdentity into a top level class and moved it to the api.meta project + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/LocationIdentity.java + graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/NamedLocationIdentity.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ReadAfterCheckCastTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/BeginLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/DirectCompareAndSwapNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/EndLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/HotSpotNmethodExecuteNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/MonitorSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/TypeCheckSnippetUtils.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StartNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MembarNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MemoryCheckpoint.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SnippetLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteMemoryCheckpointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorEnterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/PointerTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectObjectStoreNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Pointer.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/Word.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: b4f12c603be5 Author: Doug Simon Date: 2013-05-22 16:27 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b4f12c603be5 added support for the runtime to specify for each foreign call whether it is re-executable and what memory locations it kills ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/BeginLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/EndLockScopeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/NewMultiArrayStubCall.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/AESCryptSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ArrayCopySnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CheckCastSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/CipherBlockChainingSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ClassSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/InstanceOfSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectCloneSnippets.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ThreadSubstitutions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/TypeCheckSnippetUtils.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/ForeignCallStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewInstanceStub.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StartNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallStateSplitNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/MembarNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SnippetLocationNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/UnsafeStoreNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteMemoryCheckpointNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/ExceptionObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorEnterNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/MonitorExitNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MonitorTest.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/DirectObjectStoreNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: 7f92277c3a37 Author: Doug Simon Date: 2013-05-22 17:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/7f92277c3a37 removed unused method DeoptimizingNode.isCallSiteDeoptimization() ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingFixedWithNextNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeWithExceptionNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/RegisterFinalizerNode.java Changeset: d734ee4f9738 Author: Doug Simon Date: 2013-05-22 22:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d734ee4f9738 Merge. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/InvokeNode.java - graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyValueUsage.java Changeset: d6d5e3dc2713 Author: Christian Humer Date: 2013-05-23 01:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d6d5e3dc2713 Implemented generation of a proper rewrite reason for generated nodes. ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/ast/CodeTreeBuilder.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/typesystem/GuardData.java Changeset: 4f2d8bf3dfb8 Author: Christian Humer Date: 2013-05-23 01:58 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/4f2d8bf3dfb8 Merge. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallStateSplitNode.java - graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyValueUsage.java Changeset: 476cbd115289 Author: Christian Humer Date: 2013-05-23 02:22 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/476cbd115289 Fixed reason generation failed for primitive generic signatures. ! graal/com.oracle.truffle.codegen.processor/src/com/oracle/truffle/codegen/processor/node/NodeCodeGenerator.java Changeset: 41de6947dbc9 Author: Bernhard Urban Date: 2013-05-23 10:57 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/41de6947dbc9 VerifyUsageWithEquals: check for null before passing it to isAssignableForm() ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java Changeset: 2eaac2c3670b Author: Bernhard Urban Date: 2013-05-23 12:00 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/2eaac2c3670b VerifyUsageWithEquals/VerifyPhase: add documentation ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/VerifyPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java Changeset: d1682d1df0a3 Author: Bernhard Urban Date: 2013-05-23 12:06 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d1682d1df0a3 VerifyUsageWithEquals: better error message ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyUsageWithEquals.java Changeset: 9dcd6f8a843b Author: Bernhard Urban Date: 2013-05-23 12:07 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/9dcd6f8a843b CompileTask: add option to print exception on compile error per default, we don't want to print the stackTrace if ExitVMOnException isn't set (for CTW), but in some situations this can be useful, e.g. in combination with the VerifyUsageWithEquals phase. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 8e33b4ebfef1 Author: Gilles Duboscq Date: 2013-05-23 13:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8e33b4ebfef1 add isGraalEnabled(vm) function in commands.py ! mx/commands.py ! mx/sanitycheck.py Changeset: 79d65c694a3b Author: Thomas Wuerthinger Date: 2013-05-23 16:49 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/79d65c694a3b Make escape analysis and phi nodes more robust with additional assertions. ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/PhiNode.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: 53bc0557baaf Author: Doug Simon Date: 2013-05-23 18:13 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/53bc0557baaf reverted temporary commenting out of MonitorTests ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/MonitorTest.java Changeset: 21b8cd853b2b Author: Doug Simon Date: 2013-05-23 18:14 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/21b8cd853b2b cleaned up api.meta tests (GRAAL-59) + graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/MethodUniverse.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestBytecodeDisassemblerProvider.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestJavaMethod.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestJavaType.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestMetaAccessProvider.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaType.java + graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TypeUniverse.java Changeset: d552919fbb05 Author: Doug Simon Date: 2013-05-23 23:23 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/d552919fbb05 Graal's code annotations are installed into codeBlobs and are thus included in disassembler output (in a non-PRODUCT build) ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/CompilationResult.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotCompiledCode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCodeInstaller.hpp ! src/share/vm/graal/graalJavaAccess.hpp From tom.deneau at amd.com Thu May 23 16:04:25 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 23 May 2013 23:04:25 +0000 Subject: conditional move Message-ID: While compiling a larger chunk of code we were handed a ConditionalMove node (which we have not implemented yet). I would like to make a smaller test case for this but java patterns that I thought would be mapping to conditional move aren't doing so. What would be a typical small test case for generating the ConditionalMove node? -- Tom Deneau From lukas.stadler at jku.at Fri May 24 01:50:57 2013 From: lukas.stadler at jku.at (Lukas Stadler) Date: Fri, 24 May 2013 10:50:57 +0200 Subject: conditional move In-Reply-To: References: Message-ID: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> The ConditionalNode is most of the time not created by the GraphBuilder directly, but it will appear later when a simple if/then/else is canonicalized. So a simple snippet that boils down to a conditional move could look like this: public static int testSnippet(int i) { if (i == 0) { return 1; } else { return 2; } } - Lukas On May 24, 2013, at 1:04 AM, "Deneau, Tom" wrote: > While compiling a larger chunk of code we were handed a ConditionalMove node > (which we have not implemented yet). I would like to make a smaller test case > for this but java patterns that I thought would be mapping to conditional move > aren't doing so. What would be a typical small test case for generating the > ConditionalMove node? > > -- Tom Deneau > From Gary.Frost at amd.com Fri May 24 08:17:47 2013 From: Gary.Frost at amd.com (Frost, Gary) Date: Fri, 24 May 2013 15:17:47 +0000 Subject: conditional move In-Reply-To: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> References: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> Message-ID: Presumably, ternaries are good candidates for this. boolean isOdd(int i){ boolean odd=((i%2)!=0)?0:1; return odd; } -----Original Message----- From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Lukas Stadler Sent: Friday, May 24, 2013 3:51 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: conditional move The ConditionalNode is most of the time not created by the GraphBuilder directly, but it will appear later when a simple if/then/else is canonicalized. So a simple snippet that boils down to a conditional move could look like this: public static int testSnippet(int i) { if (i == 0) { return 1; } else { return 2; } } - Lukas On May 24, 2013, at 1:04 AM, "Deneau, Tom" wrote: > While compiling a larger chunk of code we were handed a > ConditionalMove node (which we have not implemented yet). I would > like to make a smaller test case for this but java patterns that I > thought would be mapping to conditional move aren't doing so. What > would be a typical small test case for generating the ConditionalMove node? > > -- Tom Deneau > From doug.simon at oracle.com Fri May 24 08:27:44 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 24 May 2013 17:27:44 +0200 Subject: conditional move In-Reply-To: References: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> Message-ID: <7D18ADF6-5118-448F-ADEB-E0061337E07A@oracle.com> Yes, because ternaries are compiled by javac as if-statements. On May 24, 2013, at 5:17 PM, "Frost, Gary" wrote: > Presumably, ternaries are good candidates for this. > > boolean isOdd(int i){ > boolean odd=((i%2)!=0)?0:1; > return odd; > } > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Lukas Stadler > Sent: Friday, May 24, 2013 3:51 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: conditional move > > The ConditionalNode is most of the time not created by the GraphBuilder directly, but it will appear later when a simple if/then/else is canonicalized. > So a simple snippet that boils down to a conditional move could look like this: > > public static int testSnippet(int i) { > if (i == 0) { > return 1; > } else { > return 2; > } > } > > - Lukas > > > On May 24, 2013, at 1:04 AM, "Deneau, Tom" wrote: > >> While compiling a larger chunk of code we were handed a >> ConditionalMove node (which we have not implemented yet). I would >> like to make a smaller test case for this but java patterns that I >> thought would be mapping to conditional move aren't doing so. What >> would be a typical small test case for generating the ConditionalMove node? >> >> -- Tom Deneau >> > > > From tom.deneau at amd.com Fri May 24 10:44:21 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 24 May 2013 17:44:21 +0000 Subject: conditional move In-Reply-To: <7D18ADF6-5118-448F-ADEB-E0061337E07A@oracle.com> References: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> <7D18ADF6-5118-448F-ADEB-E0061337E07A@oracle.com> Message-ID: My first attempts at this used ternaries and did not hit ConditionalMove but maybe I was obscuring the ConditionalMove by something else. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, May 24, 2013 10:28 AM To: Frost, Gary Cc: Lukas Stadler; Deneau, Tom; graal-dev at openjdk.java.net Subject: Re: conditional move Yes, because ternaries are compiled by javac as if-statements. On May 24, 2013, at 5:17 PM, "Frost, Gary" wrote: > Presumably, ternaries are good candidates for this. > > boolean isOdd(int i){ > boolean odd=((i%2)!=0)?0:1; > return odd; > } > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Lukas Stadler > Sent: Friday, May 24, 2013 3:51 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: conditional move > > The ConditionalNode is most of the time not created by the GraphBuilder directly, but it will appear later when a simple if/then/else is canonicalized. > So a simple snippet that boils down to a conditional move could look like this: > > public static int testSnippet(int i) { > if (i == 0) { > return 1; > } else { > return 2; > } > } > > - Lukas > > > On May 24, 2013, at 1:04 AM, "Deneau, Tom" wrote: > >> While compiling a larger chunk of code we were handed a >> ConditionalMove node (which we have not implemented yet). I would >> like to make a smaller test case for this but java patterns that I >> thought would be mapping to conditional move aren't doing so. What >> would be a typical small test case for generating the ConditionalMove node? >> >> -- Tom Deneau >> > > > From tom.deneau at amd.com Fri May 24 16:42:25 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 24 May 2013 23:42:25 +0000 Subject: conditional move In-Reply-To: <7D18ADF6-5118-448F-ADEB-E0061337E07A@oracle.com> References: <94EEBC17-CD7A-4881-9C33-A05E6C65487C@jku.at> <7D18ADF6-5118-448F-ADEB-E0061337E07A@oracle.com> Message-ID: I noticed that this code emits a Conditional Move node public int test(int a, int b) { return (a < b ? 1 : 2); } but this one does not public float test(int a, int b) { return (a < b ? 1.0f : 2.0f); } -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, May 24, 2013 10:28 AM To: Frost, Gary Cc: Lukas Stadler; Deneau, Tom; graal-dev at openjdk.java.net Subject: Re: conditional move Yes, because ternaries are compiled by javac as if-statements. On May 24, 2013, at 5:17 PM, "Frost, Gary" wrote: > Presumably, ternaries are good candidates for this. > > boolean isOdd(int i){ > boolean odd=((i%2)!=0)?0:1; > return odd; > } > > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Lukas Stadler > Sent: Friday, May 24, 2013 3:51 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: conditional move > > The ConditionalNode is most of the time not created by the GraphBuilder directly, but it will appear later when a simple if/then/else is canonicalized. > So a simple snippet that boils down to a conditional move could look like this: > > public static int testSnippet(int i) { > if (i == 0) { > return 1; > } else { > return 2; > } > } > > - Lukas > > > On May 24, 2013, at 1:04 AM, "Deneau, Tom" wrote: > >> While compiling a larger chunk of code we were handed a >> ConditionalMove node (which we have not implemented yet). I would >> like to make a smaller test case for this but java patterns that I >> thought would be mapping to conditional move aren't doing so. What >> would be a typical small test case for generating the ConditionalMove node? >> >> -- Tom Deneau >> > > > From morris.meyer at oracle.com Fri May 24 20:24:50 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Fri, 24 May 2013 23:24:50 -0400 Subject: Initial SPARC compilation test Message-ID: <51A02F02.3020802@oracle.com> I just pushed the initial SPARC compilation test for Graal. ./mx.sh --vm server unittest BasicSPARCTest will get you started. --mm From doug.simon at oracle.com Sat May 25 02:54:34 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 25 May 2013 11:54:34 +0200 Subject: Initial SPARC compilation test In-Reply-To: <51A02F02.3020802@oracle.com> References: <51A02F02.3020802@oracle.com> Message-ID: <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> Hi Morris, Christian, Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. -Doug On May 25, 2013, at 5:24 AM, Morris Meyer wrote: > I just pushed the initial SPARC compilation test for Graal. > > ./mx.sh --vm server unittest BasicSPARCTest > > will get you started. > > --mm > > From morris.meyer at oracle.com Sat May 25 06:57:53 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Sat, 25 May 2013 09:57:53 -0400 Subject: Initial SPARC compilation test In-Reply-To: <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> Message-ID: Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. The warning is handled in the lir.sparc package with a JDT prefs change. --mm On May 25, 2013, at 5:54 AM, Doug Simon wrote: > Hi Morris, Christian, > > Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. > > -Doug > > On May 25, 2013, at 5:24 AM, Morris Meyer wrote: > >> I just pushed the initial SPARC compilation test for Graal. >> >> ./mx.sh --vm server unittest BasicSPARCTest >> >> will get you started. >> >> --mm > From doug.simon at oracle.com Sat May 25 14:07:14 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 25 May 2013 23:07:14 +0200 Subject: Initial SPARC compilation test In-Reply-To: References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> Message-ID: Hi Morris, On May 25, 2013, at 3:57 PM, Morris Meyer wrote: > Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. > > I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? > The warning is handled in the lir.sparc package with a JDT prefs change. Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate -Doug [1] https://wikis.oracle.com/display/MaxineVM/Assembler > > --mm > > > On May 25, 2013, at 5:54 AM, Doug Simon wrote: > >> Hi Morris, Christian, >> >> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >> >> -Doug >> >> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >> >>> I just pushed the initial SPARC compilation test for Graal. >>> >>> ./mx.sh --vm server unittest BasicSPARCTest >>> >>> will get you started. >>> >>> --mm >> From doug.simon at oracle.com Sat May 25 14:12:21 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 25 May 2013 23:12:21 +0200 Subject: Initial SPARC compilation test In-Reply-To: References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> Message-ID: <59BDE2A9-657C-4F72-AE31-5A8D9B881B13@oracle.com> Hi Morris, On May 25, 2013, at 3:57 PM, Morris Meyer wrote: > Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. > > I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? > The warning is handled in the lir.sparc package with a JDT prefs change. Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate objects per instruction is an advantage. -Doug [1] https://wikis.oracle.com/display/MaxineVM/Assembler > > --mm > > > On May 25, 2013, at 5:54 AM, Doug Simon wrote: > >> Hi Morris, Christian, >> >> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >> >> -Doug >> >> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >> >>> I just pushed the initial SPARC compilation test for Graal. >>> >>> ./mx.sh --vm server unittest BasicSPARCTest >>> >>> will get you started. >>> >>> --mm >> From doug.simon at oracle.com Sat May 25 18:00:06 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 26 May 2013 01:00:06 +0000 Subject: hg: graal/graal: 15 new changesets Message-ID: <20130526010100.3096C48D3F@hg.openjdk.java.net> Changeset: 12fdb8fe0a35 Author: Lukas Stadler Date: 2013-05-17 15:41 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/12fdb8fe0a35 turn assertions in NodeClass.FieldScanner into guarantees ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java Changeset: a8a5d5832def Author: Lukas Stadler Date: 2013-05-17 16:47 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/a8a5d5832def first step towards extensibility of the escape analysis phase ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ReentrantBlockIterator.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/BlockState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeAnalysisPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java + graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualUtil.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: b49fdcee6cb0 Author: Lukas Stadler Date: 2013-05-23 14:44 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/b49fdcee6cb0 Merge - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/MonitorEnterStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/ThreadIsInterruptedStubCall.java - graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/VerifyOopStubCall.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallStateSplitNode.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java - graal/com.oracle.graal.phases/src/com/oracle/graal/phases/verify/VerifyValueUsage.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: 097630441baf Author: Lukas Stadler Date: 2013-05-24 11:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/097630441baf Merge ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualizerToolImpl.java Changeset: 8a3242d49786 Author: Lukas Stadler Date: 2013-05-24 11:38 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8a3242d49786 move @SuppressWarnings from local var to method ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: c010c12ab682 Author: Doug Simon Date: 2013-05-24 12:02 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/c010c12ab682 put disassembling of installed code under the control of Debug.log(); use -G:Log=CodeInstall to show disassembly for all installed code ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java Changeset: e723f9031785 Author: Morris Meyer Date: 2013-05-24 10:37 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/e723f9031785 re-architected SPARC assembler to be Fmt class specific, initial arithmetic ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java + graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/BasicSPARCTest.java + graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/SPARCTestBase.java + graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCBackend.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java + graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! make/build-graal.xml ! mx/projects Changeset: 138798dfe8dc Author: Christian Wimmer Date: 2013-05-24 15:38 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/138798dfe8dc Do not call kind() for deleted nodes, since it can cause an exception ! graal/com.oracle.graal.java/src/com/oracle/graal/java/FrameStateBuilder.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ValueNodeUtil.java Changeset: 4e9854086532 Author: Morris Meyer Date: 2013-05-24 22:51 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/4e9854086532 Initial SPARC compilation test ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotGraalRuntime.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java + graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.sparc/src/com/oracle/graal/sparc/SPARC.java ! mx/projects Changeset: 26960d32552c Author: Morris Meyer Date: 2013-05-25 16:24 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/26960d32552c SPARC integer arithmetic ! graal/com.oracle.graal.asm.sparc/src/com/oracle/graal/asm/sparc/SPARCAssembler.java + graal/com.oracle.graal.compiler.sparc.test/src/com/oracle/graal/compiler/sparc/test/IntegerSPARCTest.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: a9517aa587c7 Author: Morris Meyer Date: 2013-05-25 17:24 -0400 URL: http://hg.openjdk.java.net/graal/graal/rev/a9517aa587c7 SPARC unused object allocation fix - graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java Changeset: 8aea948c522b Author: Doug Simon Date: 2013-05-25 23:33 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/8aea948c522b added support for the runtime to specify for each foreign call whether deoptimization can occur during the call ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ForeignCallNode.java Changeset: 1b60f639ac4b Author: Doug Simon Date: 2013-05-25 23:42 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/1b60f639ac4b implemented alternative implementation for loading the exception object from the thread at the start of an exception dispatcher ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/LoadExceptionObjectSnippets.java ! graal/com.oracle.graal.replacements.test/src/com/oracle/graal/replacements/test/CompiledExceptionHandlerTest.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalRuntime.cpp ! src/share/vm/graal/graalRuntime.hpp Changeset: 32d8115dade8 Author: Doug Simon Date: 2013-05-26 00:01 +0200 URL: http://hg.openjdk.java.net/graal/graal/rev/32d8115dade8 Merge. - graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs Changeset: e210293dca77 Author: Chris Seaton Date: 2013-05-25 16:31 -0700 URL: http://hg.openjdk.java.net/graal/graal/rev/e210293dca77 Generated hashCode and equals for SourceSection. Source is abstract, so just uses identity methods for that. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/SourceSection.java From tom.deneau at amd.com Tue May 28 08:13:25 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 28 May 2013 15:13:25 +0000 Subject: graal inlining decisions Message-ID: What would be the best command line to use to see what kind of inlining decisions are being made in graal? -- Tom From mick.jordan at oracle.com Tue May 28 09:08:05 2013 From: mick.jordan at oracle.com (Mick Jordan) Date: Tue, 28 May 2013 09:08:05 -0700 Subject: graal inlining decisions In-Reply-To: References: Message-ID: <51A4D665.3020703@oracle.com> On 5/28/13 8:13 AM, Deneau, Tom wrote: > What would be the best command line to use to see what kind of inlining decisions are being made in graal? > > -- Tom This works for me: -G:Log=InliningDecisions Mick From christian.thalinger at oracle.com Tue May 28 10:48:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 May 2013 10:48:02 -0700 Subject: Initial SPARC compilation test In-Reply-To: References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> Message-ID: <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> On May 25, 2013, at 2:07 PM, Doug Simon wrote: > Hi Morris, > > On May 25, 2013, at 3:57 PM, Morris Meyer wrote: > >> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. Yes, this is my fault. Don't blame Morris :-) > > As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. Right. Remind me, why was it not used in the end? > >> >> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. > > The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? It could. It seems like a good idea to use the Java class hierarchy to represent the instruction classes of an ISA but if it causes too much trouble then we can drop it. -- Chris > >> The warning is handled in the lir.sparc package with a JDT prefs change. > > Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. > > For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate > > -Doug > > [1] https://wikis.oracle.com/display/MaxineVM/Assembler > >> >> --mm >> >> >> On May 25, 2013, at 5:54 AM, Doug Simon wrote: >> >>> Hi Morris, Christian, >>> >>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >>> >>> -Doug >>> >>> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >>> >>>> I just pushed the initial SPARC compilation test for Graal. >>>> >>>> ./mx.sh --vm server unittest BasicSPARCTest >>>> >>>> will get you started. >>>> >>>> --mm >>> > From christian.thalinger at oracle.com Tue May 28 10:54:17 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 May 2013 10:54:17 -0700 Subject: graal inlining decisions In-Reply-To: <51A4D665.3020703@oracle.com> References: <51A4D665.3020703@oracle.com> Message-ID: On May 28, 2013, at 9:08 AM, Mick Jordan wrote: > On 5/28/13 8:13 AM, Deneau, Tom wrote: >> What would be the best command line to use to see what kind of inlining decisions are being made in graal? >> >> -- Tom > This works for me: > > -G:Log=InliningDecisions I've added PrintInlining some time ago. It produces similar output as the one you already know from HotSpot. It also includes Graal's inlining decisions. 0 5 java.lang.String::replace(char, char) (127 bytes) @ 1 java.lang.Object.():void (1 bytes) trivial (nodes=4) @ 121 java.lang.String.(char[], boolean):void (15 bytes) relevance-based (relevance=0.994558, nodes=10) (Note: it's up-side down because of some recent changes in the inlining policy. It will be fixed at some point.) -- Chris > > Mick > From doug.simon at oracle.com Tue May 28 11:59:13 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 28 May 2013 20:59:13 +0200 Subject: Initial SPARC compilation test In-Reply-To: <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> Message-ID: On May 28, 2013, at 7:48 PM, Christian Thalinger wrote: > > On May 25, 2013, at 2:07 PM, Doug Simon wrote: > >> Hi Morris, >> >> On May 25, 2013, at 3:57 PM, Morris Meyer wrote: >> >>> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. > > Yes, this is my fault. Don't blame Morris :-) Blame? I had no intention of assigning blame ;-) Just trying to understand the advantage(s) of doing it this way. >> As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. > > Right. Remind me, why was it not used in the end? Because the port of C1 into C1X was intended to be as disconnected from existing Maxine technology as possible (to demonstrate the runtime/compiled interface designed as part of the porting process). Had we not moved onto Graal, there were thoughts of having the hand assembler in C1X be generated by the framework. >>> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. >> >> The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? > > It could. It seems like a good idea to use the Java class hierarchy to represent the instruction classes of an ISA but if it causes too much trouble then we can drop it. I have no strong preference. I was just looking for the technical advantage of modeling the instructions with classes that motivated the use of side-effecting constructors. In any case, it's great to see a second backend being added to Graal. -Doug > > -- Chris > >> >>> The warning is handled in the lir.sparc package with a JDT prefs change. >> >> Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. >> >> For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate >> >> -Doug >> >> [1] https://wikis.oracle.com/display/MaxineVM/Assembler >> >>> >>> --mm >>> >>> >>> On May 25, 2013, at 5:54 AM, Doug Simon wrote: >>> >>>> Hi Morris, Christian, >>>> >>>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >>>> >>>> -Doug >>>> >>>> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >>>> >>>>> I just pushed the initial SPARC compilation test for Graal. >>>>> >>>>> ./mx.sh --vm server unittest BasicSPARCTest >>>>> >>>>> will get you started. >>>>> >>>>> --mm >>>> >> > From thomas.wuerthinger at oracle.com Tue May 28 13:28:03 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 28 May 2013 22:28:03 +0200 Subject: Initial SPARC compilation test In-Reply-To: References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> Message-ID: <98CF2C01-4D13-4193-A5C8-07BFD551CA6F@oracle.com> In general, I like the idea of representing the instructions using a Java class hierarchy. What about using a pattern like new InstructionXY(?).emit(?) to avoid the side-effecting constructor? - thomas On May 28, 2013, at 8:59 PM, Doug Simon wrote: > > On May 28, 2013, at 7:48 PM, Christian Thalinger wrote: > >> >> On May 25, 2013, at 2:07 PM, Doug Simon wrote: >> >>> Hi Morris, >>> >>> On May 25, 2013, at 3:57 PM, Morris Meyer wrote: >>> >>>> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. >> >> Yes, this is my fault. Don't blame Morris :-) > > Blame? I had no intention of assigning blame ;-) Just trying to understand the advantage(s) of doing it this way. > >>> As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. >> >> Right. Remind me, why was it not used in the end? > > Because the port of C1 into C1X was intended to be as disconnected from existing Maxine technology as possible (to demonstrate the runtime/compiled interface designed as part of the porting process). Had we not moved onto Graal, there were thoughts of having the hand assembler in C1X be generated by the framework. > >>>> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. >>> >>> The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? >> >> It could. It seems like a good idea to use the Java class hierarchy to represent the instruction classes of an ISA but if it causes too much trouble then we can drop it. > > I have no strong preference. I was just looking for the technical advantage of modeling the instructions with classes that motivated the use of side-effecting constructors. > > In any case, it's great to see a second backend being added to Graal. > > -Doug > >> >> -- Chris >> >>> >>>> The warning is handled in the lir.sparc package with a JDT prefs change. >>> >>> Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. >>> >>> For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate >>> >>> -Doug >>> >>> [1] https://wikis.oracle.com/display/MaxineVM/Assembler >>> >>>> >>>> --mm >>>> >>>> >>>> On May 25, 2013, at 5:54 AM, Doug Simon wrote: >>>> >>>>> Hi Morris, Christian, >>>>> >>>>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >>>>> >>>>> -Doug >>>>> >>>>> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >>>>> >>>>>> I just pushed the initial SPARC compilation test for Graal. >>>>>> >>>>>> ./mx.sh --vm server unittest BasicSPARCTest >>>>>> >>>>>> will get you started. >>>>>> >>>>>> --mm >>>>> >>> >> > From doug.simon at oracle.com Tue May 28 13:42:16 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 28 May 2013 22:42:16 +0200 Subject: Initial SPARC compilation test In-Reply-To: <98CF2C01-4D13-4193-A5C8-07BFD551CA6F@oracle.com> References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> <98CF2C01-4D13-4193-A5C8-07BFD551CA6F@oracle.com> Message-ID: <0A95D2A7-72DD-44EC-91F6-502AEF85745A@oracle.com> On May 28, 2013, at 10:28 PM, Thomas Wuerthinger wrote: > In general, I like the idea of representing the instructions using a Java class hierarchy. What about using a pattern like new InstructionXY(?).emit(?) to avoid the side-effecting constructor? This make the Fmt classes bigger as they would define fields for the operands and they need to define an emit() method. For example, we currently we have: public static class Fmt3b { public Fmt3b(SPARCAssembler masm, int op, int op3, int rs1, int regOrImmediate, int rd) { assert op == 2 || op == 3; assert op3 >= 0 && op3 < 0x40; assert rs1 >= 0 && rs1 < 0x20; assert rd >= 0 && rd < 0x20; masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); } } public static class Add extends Fmt3b { public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); } public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); } } and we would go to: public static class Fmt3b { final int op; final int op3; final int rs1; final int regOrImmediate; int rd; public Fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { assert op == 2 || op == 3; assert op3 >= 0 && op3 < 0x40; assert rs1 >= 0 && rs1 < 0x20; assert rd >= 0 && rd < 0x20; this.op = op; this.op3 = op3; this.rs1 = rs1; this.regOrImmediate = regOrImmediate; } public emit(SPARCAssembler masm) { masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); } } public static class Add extends Fmt3b { public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); } public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); } } If we do without instruction classes, we'd have: void fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { assert op == 2 || op == 3; assert op3 >= 0 && op3 < 0x40; assert rs1 >= 0 && rs1 < 0x20; assert rd >= 0 && rd < 0x20; emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); } void add(Register src1, int simm13, Register dst) { fmt3b(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); } void add(Register src1, Register src2, Register dst) { super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); } As long as the above are non-static methods in SPARCAssembler, we still have extensibility with less code. -Doug > > - thomas > > On May 28, 2013, at 8:59 PM, Doug Simon wrote: > >> >> On May 28, 2013, at 7:48 PM, Christian Thalinger wrote: >> >>> >>> On May 25, 2013, at 2:07 PM, Doug Simon wrote: >>> >>>> Hi Morris, >>>> >>>> On May 25, 2013, at 3:57 PM, Morris Meyer wrote: >>>> >>>>> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. >>> >>> Yes, this is my fault. Don't blame Morris :-) >> >> Blame? I had no intention of assigning blame ;-) Just trying to understand the advantage(s) of doing it this way. >> >>>> As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. >>> >>> Right. Remind me, why was it not used in the end? >> >> Because the port of C1 into C1X was intended to be as disconnected from existing Maxine technology as possible (to demonstrate the runtime/compiled interface designed as part of the porting process). Had we not moved onto Graal, there were thoughts of having the hand assembler in C1X be generated by the framework. >> >>>>> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. >>>> >>>> The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? >>> >>> It could. It seems like a good idea to use the Java class hierarchy to represent the instruction classes of an ISA but if it causes too much trouble then we can drop it. >> >> I have no strong preference. I was just looking for the technical advantage of modeling the instructions with classes that motivated the use of side-effecting constructors. >> >> In any case, it's great to see a second backend being added to Graal. >> >> -Doug >> >>> >>> -- Chris >>> >>>> >>>>> The warning is handled in the lir.sparc package with a JDT prefs change. >>>> >>>> Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. >>>> >>>> For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate >>>> >>>> -Doug >>>> >>>> [1] https://wikis.oracle.com/display/MaxineVM/Assembler >>>> >>>>> >>>>> --mm >>>>> >>>>> >>>>> On May 25, 2013, at 5:54 AM, Doug Simon wrote: >>>>> >>>>>> Hi Morris, Christian, >>>>>> >>>>>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >>>>>> >>>>>> -Doug >>>>>> >>>>>> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >>>>>> >>>>>>> I just pushed the initial SPARC compilation test for Graal. >>>>>>> >>>>>>> ./mx.sh --vm server unittest BasicSPARCTest >>>>>>> >>>>>>> will get you started. >>>>>>> >>>>>>> --mm >>>>>> >>>> >>> >> > From thomas.wuerthinger at oracle.com Tue May 28 13:52:18 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 28 May 2013 22:52:18 +0200 Subject: Initial SPARC compilation test In-Reply-To: <0A95D2A7-72DD-44EC-91F6-502AEF85745A@oracle.com> References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> <98CF2C01-4D13-4193-A5C8-07BFD551CA6F@oracle.com> <0A95D2A7-72DD-44EC-91F6-502AEF85745A@oracle.com> Message-ID: The possible benefits of having instruction classes would include abilities like writing simulation or verification code. This would include the field definitions you outline below. In the machine code, it would not make any performance difference as escape analysis would still get rid of the allocation for the case where the instruction instance is not stored in a side data structure. If we do not have the fields, then I see no benefit of using constructors over static methods. - thomas On May 28, 2013, at 10:42 PM, Doug Simon wrote: > > On May 28, 2013, at 10:28 PM, Thomas Wuerthinger wrote: > >> In general, I like the idea of representing the instructions using a Java class hierarchy. What about using a pattern like new InstructionXY(?).emit(?) to avoid the side-effecting constructor? > > This make the Fmt classes bigger as they would define fields for the operands and they need to define an emit() method. For example, we currently we have: > > public static class Fmt3b { > public Fmt3b(SPARCAssembler masm, int op, int op3, int rs1, int regOrImmediate, int rd) { > assert op == 2 || op == 3; > assert op3 >= 0 && op3 < 0x40; > assert rs1 >= 0 && rs1 < 0x20; > assert rd >= 0 && rd < 0x20; > > masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); > } > } > > public static class Add extends Fmt3b { > public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { > super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); > } > public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { > super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); > } > } > > and we would go to: > > public static class Fmt3b { > final int op; > final int op3; > final int rs1; > final int regOrImmediate; > int rd; > public Fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { > assert op == 2 || op == 3; > assert op3 >= 0 && op3 < 0x40; > assert rs1 >= 0 && rs1 < 0x20; > assert rd >= 0 && rd < 0x20; > this.op = op; > this.op3 = op3; > this.rs1 = rs1; > this.regOrImmediate = regOrImmediate; > } > public emit(SPARCAssembler masm) { > masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); > } > } > > public static class Add extends Fmt3b { > public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { > super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); > } > public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { > super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); > } > } > > If we do without instruction classes, we'd have: > > void fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { > assert op == 2 || op == 3; > assert op3 >= 0 && op3 < 0x40; > assert rs1 >= 0 && rs1 < 0x20; > assert rd >= 0 && rd < 0x20; > > emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); > } > > void add(Register src1, int simm13, Register dst) { > fmt3b(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); > } > > void add(Register src1, Register src2, Register dst) { > super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); > } > > As long as the above are non-static methods in SPARCAssembler, we still have extensibility with less code. > > -Doug > >> >> - thomas >> >> On May 28, 2013, at 8:59 PM, Doug Simon wrote: >> >>> >>> On May 28, 2013, at 7:48 PM, Christian Thalinger wrote: >>> >>>> >>>> On May 25, 2013, at 2:07 PM, Doug Simon wrote: >>>> >>>>> Hi Morris, >>>>> >>>>> On May 25, 2013, at 3:57 PM, Morris Meyer wrote: >>>>> >>>>>> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. >>>> >>>> Yes, this is my fault. Don't blame Morris :-) >>> >>> Blame? I had no intention of assigning blame ;-) Just trying to understand the advantage(s) of doing it this way. >>> >>>>> As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. >>>> >>>> Right. Remind me, why was it not used in the end? >>> >>> Because the port of C1 into C1X was intended to be as disconnected from existing Maxine technology as possible (to demonstrate the runtime/compiled interface designed as part of the porting process). Had we not moved onto Graal, there were thoughts of having the hand assembler in C1X be generated by the framework. >>> >>>>>> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. >>>>> >>>>> The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? >>>> >>>> It could. It seems like a good idea to use the Java class hierarchy to represent the instruction classes of an ISA but if it causes too much trouble then we can drop it. >>> >>> I have no strong preference. I was just looking for the technical advantage of modeling the instructions with classes that motivated the use of side-effecting constructors. >>> >>> In any case, it's great to see a second backend being added to Graal. >>> >>> -Doug >>> >>>> >>>> -- Chris >>>> >>>>> >>>>>> The warning is handled in the lir.sparc package with a JDT prefs change. >>>>> >>>>> Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. >>>>> >>>>> For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate >>>>> >>>>> -Doug >>>>> >>>>> [1] https://wikis.oracle.com/display/MaxineVM/Assembler >>>>> >>>>>> >>>>>> --mm >>>>>> >>>>>> >>>>>> On May 25, 2013, at 5:54 AM, Doug Simon wrote: >>>>>> >>>>>>> Hi Morris, Christian, >>>>>>> >>>>>>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >>>>>>> >>>>>>> -Doug >>>>>>> >>>>>>> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >>>>>>> >>>>>>>> I just pushed the initial SPARC compilation test for Graal. >>>>>>>> >>>>>>>> ./mx.sh --vm server unittest BasicSPARCTest >>>>>>>> >>>>>>>> will get you started. >>>>>>>> >>>>>>>> --mm >>>>>>> >>>>> >>>> >>> >> > From doug.simon at oracle.com Tue May 28 13:58:30 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 28 May 2013 22:58:30 +0200 Subject: Initial SPARC compilation test In-Reply-To: References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> <98CF2C01-4D13-4193-A5C8-07BFD551CA6F@oracle.com> <0A95D2A7-72DD-44EC-91F6-502AEF85745A@oracle.com> Message-ID: On May 28, 2013, at 10:52 PM, Thomas Wuerthinger wrote: > The possible benefits of having instruction classes would include abilities like writing simulation or verification code. True. It also makes the classes usable as output for a structured disassembler. > This would include the field definitions you outline below. In the machine code, it would not make any performance difference as escape analysis would still get rid of the allocation for the case where the instruction instance is not stored in a side data structure. Yes, I have complete faith in escape analysis, especially in this case. > If we do not have the fields, then I see no benefit of using constructors over static methods. Right. The use cases mentioned above are interesting however though. -Doug > On May 28, 2013, at 10:42 PM, Doug Simon wrote: > >> >> On May 28, 2013, at 10:28 PM, Thomas Wuerthinger wrote: >> >>> In general, I like the idea of representing the instructions using a Java class hierarchy. What about using a pattern like new InstructionXY(?).emit(?) to avoid the side-effecting constructor? >> >> This make the Fmt classes bigger as they would define fields for the operands and they need to define an emit() method. For example, we currently we have: >> >> public static class Fmt3b { >> public Fmt3b(SPARCAssembler masm, int op, int op3, int rs1, int regOrImmediate, int rd) { >> assert op == 2 || op == 3; >> assert op3 >= 0 && op3 < 0x40; >> assert rs1 >= 0 && rs1 < 0x20; >> assert rd >= 0 && rd < 0x20; >> >> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >> } >> } >> >> public static class Add extends Fmt3b { >> public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { >> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >> } >> public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { >> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >> } >> } >> >> and we would go to: >> >> public static class Fmt3b { >> final int op; >> final int op3; >> final int rs1; >> final int regOrImmediate; >> int rd; >> public Fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { >> assert op == 2 || op == 3; >> assert op3 >= 0 && op3 < 0x40; >> assert rs1 >= 0 && rs1 < 0x20; >> assert rd >= 0 && rd < 0x20; >> this.op = op; >> this.op3 = op3; >> this.rs1 = rs1; >> this.regOrImmediate = regOrImmediate; >> } >> public emit(SPARCAssembler masm) { >> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >> } >> } >> >> public static class Add extends Fmt3b { >> public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { >> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >> } >> public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { >> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >> } >> } >> >> If we do without instruction classes, we'd have: >> >> void fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { >> assert op == 2 || op == 3; >> assert op3 >= 0 && op3 < 0x40; >> assert rs1 >= 0 && rs1 < 0x20; >> assert rd >= 0 && rd < 0x20; >> >> emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >> } >> >> void add(Register src1, int simm13, Register dst) { >> fmt3b(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >> } >> >> void add(Register src1, Register src2, Register dst) { >> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >> } >> >> As long as the above are non-static methods in SPARCAssembler, we still have extensibility with less code. >> >> -Doug >> >>> >>> - thomas >>> >>> On May 28, 2013, at 8:59 PM, Doug Simon wrote: >>> >>>> >>>> On May 28, 2013, at 7:48 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On May 25, 2013, at 2:07 PM, Doug Simon wrote: >>>>> >>>>>> Hi Morris, >>>>>> >>>>>> On May 25, 2013, at 3:57 PM, Morris Meyer wrote: >>>>>> >>>>>>> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. >>>>> >>>>> Yes, this is my fault. Don't blame Morris :-) >>>> >>>> Blame? I had no intention of assigning blame ;-) Just trying to understand the advantage(s) of doing it this way. >>>> >>>>>> As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. >>>>> >>>>> Right. Remind me, why was it not used in the end? >>>> >>>> Because the port of C1 into C1X was intended to be as disconnected from existing Maxine technology as possible (to demonstrate the runtime/compiled interface designed as part of the porting process). Had we not moved onto Graal, there were thoughts of having the hand assembler in C1X be generated by the framework. >>>> >>>>>>> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. >>>>>> >>>>>> The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? >>>>> >>>>> It could. It seems like a good idea to use the Java class hierarchy to represent the instruction classes of an ISA but if it causes too much trouble then we can drop it. >>>> >>>> I have no strong preference. I was just looking for the technical advantage of modeling the instructions with classes that motivated the use of side-effecting constructors. >>>> >>>> In any case, it's great to see a second backend being added to Graal. >>>> >>>> -Doug >>>> >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>>> The warning is handled in the lir.sparc package with a JDT prefs change. >>>>>> >>>>>> Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. >>>>>> >>>>>> For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate >>>>>> >>>>>> -Doug >>>>>> >>>>>> [1] https://wikis.oracle.com/display/MaxineVM/Assembler >>>>>> >>>>>>> >>>>>>> --mm >>>>>>> >>>>>>> >>>>>>> On May 25, 2013, at 5:54 AM, Doug Simon wrote: >>>>>>> >>>>>>>> Hi Morris, Christian, >>>>>>>> >>>>>>>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >>>>>>>> >>>>>>>> -Doug >>>>>>>> >>>>>>>> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >>>>>>>> >>>>>>>>> I just pushed the initial SPARC compilation test for Graal. >>>>>>>>> >>>>>>>>> ./mx.sh --vm server unittest BasicSPARCTest >>>>>>>>> >>>>>>>>> will get you started. >>>>>>>>> >>>>>>>>> --mm >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From christian.thalinger at oracle.com Tue May 28 15:27:27 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 May 2013 15:27:27 -0700 Subject: Initial SPARC compilation test In-Reply-To: References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> <98CF2C01-4D13-4193-A5C8-07BFD551CA6F@oracle.com> <0A95D2A7-72DD-44EC-91F6-502AEF85745A@oracle.com> Message-ID: <440BBC4B-BD2E-48EA-9753-7E308ADFDF5B@oracle.com> On May 28, 2013, at 1:58 PM, Doug Simon wrote: > > On May 28, 2013, at 10:52 PM, Thomas Wuerthinger wrote: > >> The possible benefits of having instruction classes would include abilities like writing simulation or verification code. > > True. It also makes the classes usable as output for a structured disassembler. That's a good point. Instruction patching could then be something like: Add.readAt(pc).setRd(reg).emit(masm); Since RISC architectures usually have a small number of instruction classes I think we should go that way. -- Chris > >> This would include the field definitions you outline below. In the machine code, it would not make any performance difference as escape analysis would still get rid of the allocation for the case where the instruction instance is not stored in a side data structure. > > Yes, I have complete faith in escape analysis, especially in this case. > >> If we do not have the fields, then I see no benefit of using constructors over static methods. > > Right. The use cases mentioned above are interesting however though. > > -Doug > >> On May 28, 2013, at 10:42 PM, Doug Simon wrote: >> >>> >>> On May 28, 2013, at 10:28 PM, Thomas Wuerthinger wrote: >>> >>>> In general, I like the idea of representing the instructions using a Java class hierarchy. What about using a pattern like new InstructionXY(?).emit(?) to avoid the side-effecting constructor? >>> >>> This make the Fmt classes bigger as they would define fields for the operands and they need to define an emit() method. For example, we currently we have: >>> >>> public static class Fmt3b { >>> public Fmt3b(SPARCAssembler masm, int op, int op3, int rs1, int regOrImmediate, int rd) { >>> assert op == 2 || op == 3; >>> assert op3 >= 0 && op3 < 0x40; >>> assert rs1 >= 0 && rs1 < 0x20; >>> assert rd >= 0 && rd < 0x20; >>> >>> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >>> } >>> } >>> >>> public static class Add extends Fmt3b { >>> public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { >>> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >>> } >>> public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { >>> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >>> } >>> } >>> >>> and we would go to: >>> >>> public static class Fmt3b { >>> final int op; >>> final int op3; >>> final int rs1; >>> final int regOrImmediate; >>> int rd; >>> public Fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { >>> assert op == 2 || op == 3; >>> assert op3 >= 0 && op3 < 0x40; >>> assert rs1 >= 0 && rs1 < 0x20; >>> assert rd >= 0 && rd < 0x20; >>> this.op = op; >>> this.op3 = op3; >>> this.rs1 = rs1; >>> this.regOrImmediate = regOrImmediate; >>> } >>> public emit(SPARCAssembler masm) { >>> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >>> } >>> } >>> >>> public static class Add extends Fmt3b { >>> public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { >>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >>> } >>> public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { >>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >>> } >>> } >>> >>> If we do without instruction classes, we'd have: >>> >>> void fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { >>> assert op == 2 || op == 3; >>> assert op3 >= 0 && op3 < 0x40; >>> assert rs1 >= 0 && rs1 < 0x20; >>> assert rd >= 0 && rd < 0x20; >>> >>> emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >>> } >>> >>> void add(Register src1, int simm13, Register dst) { >>> fmt3b(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >>> } >>> >>> void add(Register src1, Register src2, Register dst) { >>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >>> } >>> >>> As long as the above are non-static methods in SPARCAssembler, we still have extensibility with less code. >>> >>> -Doug >>> >>>> >>>> - thomas >>>> >>>> On May 28, 2013, at 8:59 PM, Doug Simon wrote: >>>> >>>>> >>>>> On May 28, 2013, at 7:48 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On May 25, 2013, at 2:07 PM, Doug Simon wrote: >>>>>> >>>>>>> Hi Morris, >>>>>>> >>>>>>> On May 25, 2013, at 3:57 PM, Morris Meyer wrote: >>>>>>> >>>>>>>> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. >>>>>> >>>>>> Yes, this is my fault. Don't blame Morris :-) >>>>> >>>>> Blame? I had no intention of assigning blame ;-) Just trying to understand the advantage(s) of doing it this way. >>>>> >>>>>>> As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. >>>>>> >>>>>> Right. Remind me, why was it not used in the end? >>>>> >>>>> Because the port of C1 into C1X was intended to be as disconnected from existing Maxine technology as possible (to demonstrate the runtime/compiled interface designed as part of the porting process). Had we not moved onto Graal, there were thoughts of having the hand assembler in C1X be generated by the framework. >>>>> >>>>>>>> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. >>>>>>> >>>>>>> The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? >>>>>> >>>>>> It could. It seems like a good idea to use the Java class hierarchy to represent the instruction classes of an ISA but if it causes too much trouble then we can drop it. >>>>> >>>>> I have no strong preference. I was just looking for the technical advantage of modeling the instructions with classes that motivated the use of side-effecting constructors. >>>>> >>>>> In any case, it's great to see a second backend being added to Graal. >>>>> >>>>> -Doug >>>>> >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>>> The warning is handled in the lir.sparc package with a JDT prefs change. >>>>>>> >>>>>>> Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. >>>>>>> >>>>>>> For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate >>>>>>> >>>>>>> -Doug >>>>>>> >>>>>>> [1] https://wikis.oracle.com/display/MaxineVM/Assembler >>>>>>> >>>>>>>> >>>>>>>> --mm >>>>>>>> >>>>>>>> >>>>>>>> On May 25, 2013, at 5:54 AM, Doug Simon wrote: >>>>>>>> >>>>>>>>> Hi Morris, Christian, >>>>>>>>> >>>>>>>>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >>>>>>>>> >>>>>>>>> -Doug >>>>>>>>> >>>>>>>>> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >>>>>>>>> >>>>>>>>>> I just pushed the initial SPARC compilation test for Graal. >>>>>>>>>> >>>>>>>>>> ./mx.sh --vm server unittest BasicSPARCTest >>>>>>>>>> >>>>>>>>>> will get you started. >>>>>>>>>> >>>>>>>>>> --mm >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From tom.deneau at amd.com Tue May 28 16:22:48 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 28 May 2013 23:22:48 +0000 Subject: graal inlining decisions In-Reply-To: <51A4D665.3020703@oracle.com> References: <51A4D665.3020703@oracle.com> Message-ID: Just to clarify, I would like to see the inlining decisions made when I compile for an HSAIL target, (not interested in any decisions made for the x86 host). When I use the line below with mx unittest I see only x86 decisions... -- Tom -----Original Message----- From: Mick Jordan [mailto:mick.jordan at oracle.com] Sent: Tuesday, May 28, 2013 11:08 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: graal inlining decisions On 5/28/13 8:13 AM, Deneau, Tom wrote: > What would be the best command line to use to see what kind of inlining decisions are being made in graal? > > -- Tom This works for me: -G:Log=InliningDecisions Mick From morris.meyer at oracle.com Wed May 29 07:56:45 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Wed, 29 May 2013 10:56:45 -0400 Subject: Initial SPARC compilation test In-Reply-To: <440BBC4B-BD2E-48EA-9753-7E308ADFDF5B@oracle.com> References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> <98CF2C01-4D13-4193-A5C8-07BFD551CA6F@oracle.com> <0A95D2A7-72DD-44EC-91F6-502AEF85745A@oracle.com> <440BBC4B-BD2E-48EA-9753-7E308ADFDF5B@oracle.com> Message-ID: <51A6172D.5020703@oracle.com> The object layout of instructions has sort of grown on me. I think the possibility for post-assembly reordering of code - such as this from the SPARC V9 spec below could have benefits. I think there is room for improvement still in SPARCAssembler with the class structure - saving the fields and separating encode from emit seems to be one. For now though I'm working on getting Graal to compile on SPARC. --mm Branches cause most implementations? performance to degrade significantly. Frrequently, the MOVcc and FMOVcc instructions can be used to avoid branches. For example, the following C language segment: double A, B, X; if (A > B) then X = 1.03; else X = 0.0; can be coded as ! assume A is in %f0; B is in %f2; %xx points to constant area ldd [%xx+C_1.03],%f4 ! X = 1.03 fcmpd %fcc3,%f0,%f2 ! A > B fble,a %fcc3,label ! following only executed if the branch is taken fsubd %f4,%f4,%f4 ! X = 0.0 label:... This takes four instructions including a branch. Using FMOVcc, this could be coded as ldd [%xx+C_1.03],%f4 ! X = 1.03 fsubd %f4,%f4,%f6! X? = 0.0 fcmpd %fcc3,%f0,%f2! A > B fmovdle %fcc3,%f6,%f4! X = 0.0 This also takes four instructions, but requires no branches and may boost performance significantly. It is sug- gested that MOVcc and FMOVcc be used instead of branches wherever they would improve performance. SPARCV9 On 5/28/13 6:27 PM, Christian Thalinger wrote: > On May 28, 2013, at 1:58 PM, Doug Simon wrote: > >> On May 28, 2013, at 10:52 PM, Thomas Wuerthinger wrote: >> >>> The possible benefits of having instruction classes would include abilities like writing simulation or verification code. >> True. It also makes the classes usable as output for a structured disassembler. > That's a good point. Instruction patching could then be something like: > > Add.readAt(pc).setRd(reg).emit(masm); > > Since RISC architectures usually have a small number of instruction classes I think we should go that way. > > -- Chris > >>> This would include the field definitions you outline below. In the machine code, it would not make any performance difference as escape analysis would still get rid of the allocation for the case where the instruction instance is not stored in a side data structure. >> Yes, I have complete faith in escape analysis, especially in this case. >> >>> If we do not have the fields, then I see no benefit of using constructors over static methods. >> Right. The use cases mentioned above are interesting however though. >> >> -Doug >> >>> On May 28, 2013, at 10:42 PM, Doug Simon wrote: >>> >>>> On May 28, 2013, at 10:28 PM, Thomas Wuerthinger wrote: >>>> >>>>> In general, I like the idea of representing the instructions using a Java class hierarchy. What about using a pattern like new InstructionXY(?).emit(?) to avoid the side-effecting constructor? >>>> This make the Fmt classes bigger as they would define fields for the operands and they need to define an emit() method. For example, we currently we have: >>>> >>>> public static class Fmt3b { >>>> public Fmt3b(SPARCAssembler masm, int op, int op3, int rs1, int regOrImmediate, int rd) { >>>> assert op == 2 || op == 3; >>>> assert op3 >= 0 && op3 < 0x40; >>>> assert rs1 >= 0 && rs1 < 0x20; >>>> assert rd >= 0 && rd < 0x20; >>>> >>>> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >>>> } >>>> } >>>> >>>> public static class Add extends Fmt3b { >>>> public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { >>>> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >>>> } >>>> public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { >>>> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >>>> } >>>> } >>>> >>>> and we would go to: >>>> >>>> public static class Fmt3b { >>>> final int op; >>>> final int op3; >>>> final int rs1; >>>> final int regOrImmediate; >>>> int rd; >>>> public Fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { >>>> assert op == 2 || op == 3; >>>> assert op3 >= 0 && op3 < 0x40; >>>> assert rs1 >= 0 && rs1 < 0x20; >>>> assert rd >= 0 && rd < 0x20; >>>> this.op = op; >>>> this.op3 = op3; >>>> this.rs1 = rs1; >>>> this.regOrImmediate = regOrImmediate; >>>> } >>>> public emit(SPARCAssembler masm) { >>>> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >>>> } >>>> } >>>> >>>> public static class Add extends Fmt3b { >>>> public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { >>>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >>>> } >>>> public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { >>>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >>>> } >>>> } >>>> >>>> If we do without instruction classes, we'd have: >>>> >>>> void fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { >>>> assert op == 2 || op == 3; >>>> assert op3 >= 0 && op3 < 0x40; >>>> assert rs1 >= 0 && rs1 < 0x20; >>>> assert rd >= 0 && rd < 0x20; >>>> >>>> emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >>>> } >>>> >>>> void add(Register src1, int simm13, Register dst) { >>>> fmt3b(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >>>> } >>>> >>>> void add(Register src1, Register src2, Register dst) { >>>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >>>> } >>>> >>>> As long as the above are non-static methods in SPARCAssembler, we still have extensibility with less code. >>>> >>>> -Doug >>>> >>>>> - thomas >>>>> >>>>> On May 28, 2013, at 8:59 PM, Doug Simon wrote: >>>>> >>>>>> On May 28, 2013, at 7:48 PM, Christian Thalinger wrote: >>>>>> >>>>>>> On May 25, 2013, at 2:07 PM, Doug Simon wrote: >>>>>>> >>>>>>>> Hi Morris, >>>>>>>> >>>>>>>> On May 25, 2013, at 3:57 PM, Morris Meyer wrote: >>>>>>>> >>>>>>>>> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. >>>>>>> Yes, this is my fault. Don't blame Morris :-) >>>>>> Blame? I had no intention of assigning blame ;-) Just trying to understand the advantage(s) of doing it this way. >>>>>> >>>>>>>> As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. >>>>>>> Right. Remind me, why was it not used in the end? >>>>>> Because the port of C1 into C1X was intended to be as disconnected from existing Maxine technology as possible (to demonstrate the runtime/compiled interface designed as part of the porting process). Had we not moved onto Graal, there were thoughts of having the hand assembler in C1X be generated by the framework. >>>>>> >>>>>>>>> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. >>>>>>>> The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? >>>>>>> It could. It seems like a good idea to use the Java class hierarchy to represent the instruction classes of an ISA but if it causes too much trouble then we can drop it. >>>>>> I have no strong preference. I was just looking for the technical advantage of modeling the instructions with classes that motivated the use of side-effecting constructors. >>>>>> >>>>>> In any case, it's great to see a second backend being added to Graal. >>>>>> >>>>>> -Doug >>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>>> The warning is handled in the lir.sparc package with a JDT prefs change. >>>>>>>> Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. >>>>>>>> >>>>>>>> For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate >>>>>>>> >>>>>>>> -Doug >>>>>>>> >>>>>>>> [1] https://wikis.oracle.com/display/MaxineVM/Assembler >>>>>>>> >>>>>>>>> --mm >>>>>>>>> >>>>>>>>> >>>>>>>>> On May 25, 2013, at 5:54 AM, Doug Simon wrote: >>>>>>>>> >>>>>>>>>> Hi Morris, Christian, >>>>>>>>>> >>>>>>>>>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >>>>>>>>>> >>>>>>>>>> -Doug >>>>>>>>>> >>>>>>>>>> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >>>>>>>>>> >>>>>>>>>>> I just pushed the initial SPARC compilation test for Graal. >>>>>>>>>>> >>>>>>>>>>> ./mx.sh --vm server unittest BasicSPARCTest >>>>>>>>>>> >>>>>>>>>>> will get you started. >>>>>>>>>>> >>>>>>>>>>> --mm From christian.thalinger at oracle.com Wed May 29 09:16:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 29 May 2013 09:16:08 -0700 Subject: Initial SPARC compilation test In-Reply-To: <51A6172D.5020703@oracle.com> References: <51A02F02.3020802@oracle.com> <8E446DA0-A873-4E57-9AD6-290BBF78394E@oracle.com> <03490880-C700-47B8-BBEA-47F0762C438D@oracle.com> <98CF2C01-4D13-4193-A5C8-07BFD551CA6F@oracle.com> <0A95D2A7-72DD-44EC-91F6-502AEF85745A@oracle.com> <440BBC4B-BD2E-48EA-9753-7E308ADFDF5B@oracle.com> <51A6172D.5020703@oracle.com> Message-ID: <664A9D4F-3E50-4929-9C8E-85A409F7537E@oracle.com> On May 29, 2013, at 7:56 AM, Morris Meyer wrote: > The object layout of instructions has sort of grown on me. I think the possibility for post-assembly reordering of code - such as this from the SPARC V9 spec below could have benefits. > > I think there is room for improvement still in SPARCAssembler with the class structure - saving the fields and separating encode from emit seems to be one. > > For now though I'm working on getting Graal to compile on SPARC. > > --mm > > Branches cause most implementations? performance to degrade significantly. Frrequently, the MOVcc and FMOVcc instructions can be used to avoid branches. For example, the following C language segment: > > double A, B, X; > if (A > B) then X = 1.03; else X = 0.0; > > can be coded as > > ! assume A is in %f0; B is in %f2; %xx points to constant area > ldd [%xx+C_1.03],%f4 ! X = 1.03 > fcmpd %fcc3,%f0,%f2 ! A > B > > fble,a %fcc3,label > > ! following only executed if the branch is taken > > fsubd %f4,%f4,%f4 ! X = 0.0 > label:... > > This takes four instructions including a branch. Using FMOVcc, this could be coded as > > ldd [%xx+C_1.03],%f4 ! X = 1.03 > > fsubd %f4,%f4,%f6! X? = 0.0 > fcmpd %fcc3,%f0,%f2! A > B > fmovdle %fcc3,%f6,%f4! X = 0.0 > > > > > This also takes four instructions, but requires no branches and may boost performance significantly. It is sug- gested that MOVcc and FMOVcc be used instead of branches wherever they would improve performance. I wonder if this is still true with newer SPARC implementations. -- Chris > > SPARCV9 > > On 5/28/13 6:27 PM, Christian Thalinger wrote: >> On May 28, 2013, at 1:58 PM, Doug Simon wrote: >> >>> On May 28, 2013, at 10:52 PM, Thomas Wuerthinger wrote: >>> >>>> The possible benefits of having instruction classes would include abilities like writing simulation or verification code. >>> True. It also makes the classes usable as output for a structured disassembler. >> That's a good point. Instruction patching could then be something like: >> >> Add.readAt(pc).setRd(reg).emit(masm); >> >> Since RISC architectures usually have a small number of instruction classes I think we should go that way. >> >> -- Chris >> >>>> This would include the field definitions you outline below. In the machine code, it would not make any performance difference as escape analysis would still get rid of the allocation for the case where the instruction instance is not stored in a side data structure. >>> Yes, I have complete faith in escape analysis, especially in this case. >>> >>>> If we do not have the fields, then I see no benefit of using constructors over static methods. >>> Right. The use cases mentioned above are interesting however though. >>> >>> -Doug >>> >>>> On May 28, 2013, at 10:42 PM, Doug Simon wrote: >>>> >>>>> On May 28, 2013, at 10:28 PM, Thomas Wuerthinger wrote: >>>>> >>>>>> In general, I like the idea of representing the instructions using a Java class hierarchy. What about using a pattern like new InstructionXY(?).emit(?) to avoid the side-effecting constructor? >>>>> This make the Fmt classes bigger as they would define fields for the operands and they need to define an emit() method. For example, we currently we have: >>>>> >>>>> public static class Fmt3b { >>>>> public Fmt3b(SPARCAssembler masm, int op, int op3, int rs1, int regOrImmediate, int rd) { >>>>> assert op == 2 || op == 3; >>>>> assert op3 >= 0 && op3 < 0x40; >>>>> assert rs1 >= 0 && rs1 < 0x20; >>>>> assert rd >= 0 && rd < 0x20; >>>>> >>>>> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >>>>> } >>>>> } >>>>> >>>>> public static class Add extends Fmt3b { >>>>> public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { >>>>> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >>>>> } >>>>> public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { >>>>> super(masm, Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >>>>> } >>>>> } >>>>> >>>>> and we would go to: >>>>> >>>>> public static class Fmt3b { >>>>> final int op; >>>>> final int op3; >>>>> final int rs1; >>>>> final int regOrImmediate; >>>>> int rd; >>>>> public Fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { >>>>> assert op == 2 || op == 3; >>>>> assert op3 >= 0 && op3 < 0x40; >>>>> assert rs1 >= 0 && rs1 < 0x20; >>>>> assert rd >= 0 && rd < 0x20; >>>>> this.op = op; >>>>> this.op3 = op3; >>>>> this.rs1 = rs1; >>>>> this.regOrImmediate = regOrImmediate; >>>>> } >>>>> public emit(SPARCAssembler masm) { >>>>> masm.emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >>>>> } >>>>> } >>>>> >>>>> public static class Add extends Fmt3b { >>>>> public Add(SPARCAssembler masm, Register src1, int simm13, Register dst) { >>>>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >>>>> } >>>>> public Add(SPARCAssembler masm, Register src1, Register src2, Register dst) { >>>>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >>>>> } >>>>> } >>>>> >>>>> If we do without instruction classes, we'd have: >>>>> >>>>> void fmt3b(int op, int op3, int rs1, int regOrImmediate, int rd) { >>>>> assert op == 2 || op == 3; >>>>> assert op3 >= 0 && op3 < 0x40; >>>>> assert rs1 >= 0 && rs1 < 0x20; >>>>> assert rd >= 0 && rd < 0x20; >>>>> >>>>> emitInt(op << 30 | rd << 25 | op3 << 19 | rs1 << 14 | (regOrImmediate & 0x1fff)); >>>>> } >>>>> >>>>> void add(Register src1, int simm13, Register dst) { >>>>> fmt3b(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), simm13, dst.encoding()); >>>>> } >>>>> >>>>> void add(Register src1, Register src2, Register dst) { >>>>> super(Ops.ArithOp.getValue(), Op3s.Add.getValue(), src1.encoding(), src2.encoding(), dst.encoding()); >>>>> } >>>>> >>>>> As long as the above are non-static methods in SPARCAssembler, we still have extensibility with less code. >>>>> >>>>> -Doug >>>>> >>>>>> - thomas >>>>>> >>>>>> On May 28, 2013, at 8:59 PM, Doug Simon wrote: >>>>>> >>>>>>> On May 28, 2013, at 7:48 PM, Christian Thalinger wrote: >>>>>>> >>>>>>>> On May 25, 2013, at 2:07 PM, Doug Simon wrote: >>>>>>>> >>>>>>>>> Hi Morris, >>>>>>>>> >>>>>>>>> On May 25, 2013, at 3:57 PM, Morris Meyer wrote: >>>>>>>>> >>>>>>>>>> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it. >>>>>>>> Yes, this is my fault. Don't blame Morris :-) >>>>>>> Blame? I had no intention of assigning blame ;-) Just trying to understand the advantage(s) of doing it this way. >>>>>>> >>>>>>>>> As part of the Maxine project, we had a system for generating assemblers[1] (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't. >>>>>>>> Right. Remind me, why was it not used in the end? >>>>>>> Because the port of C1 into C1X was intended to be as disconnected from existing Maxine technology as possible (to demonstrate the runtime/compiled interface designed as part of the porting process). Had we not moved onto Graal, there were thoughts of having the hand assembler in C1X be generated by the framework. >>>>>>> >>>>>>>>>> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier. >>>>>>>>> The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right? >>>>>>>> It could. It seems like a good idea to use the Java class hierarchy to represent the instruction classes of an ISA but if it causes too much trouble then we can drop it. >>>>>>> I have no strong preference. I was just looking for the technical advantage of modeling the instructions with classes that motivated the use of side-effecting constructors. >>>>>>> >>>>>>> In any case, it's great to see a second backend being added to Graal. >>>>>>> >>>>>>> -Doug >>>>>>> >>>>>>>> -- Chris >>>>>>>> >>>>>>>>>> The warning is handled in the lir.sparc package with a JDT prefs change. >>>>>>>>> Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten. >>>>>>>>> >>>>>>>>> For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate >>>>>>>>> >>>>>>>>> -Doug >>>>>>>>> >>>>>>>>> [1] https://wikis.oracle.com/display/MaxineVM/Assembler >>>>>>>>> >>>>>>>>>> --mm >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On May 25, 2013, at 5:54 AM, Doug Simon wrote: >>>>>>>>>> >>>>>>>>>>> Hi Morris, Christian, >>>>>>>>>>> >>>>>>>>>>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow. >>>>>>>>>>> >>>>>>>>>>> -Doug >>>>>>>>>>> >>>>>>>>>>> On May 25, 2013, at 5:24 AM, Morris Meyer wrote: >>>>>>>>>>> >>>>>>>>>>>> I just pushed the initial SPARC compilation test for Graal. >>>>>>>>>>>> >>>>>>>>>>>> ./mx.sh --vm server unittest BasicSPARCTest >>>>>>>>>>>> >>>>>>>>>>>> will get you started. >>>>>>>>>>>> >>>>>>>>>>>> --mm > From Vasanth.Venkatachalam at amd.com Wed May 29 13:06:01 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Wed, 29 May 2013 20:06:01 +0000 Subject: disabling arithmetic nodes with memory operands Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8CBE14@sausexdag06.amd.com> Hi, For an arithmetic test case involving doubles, Graal is generating a node for a double addition where one of the arguments is a stack slot. Unlike x86, HSAIL doesn't support passing a stack slot or memory address as one of the arguments to an addition. The HSAIL backend I've developed would have to load the value from the stack into a register first and do a register to register addition. Since this hasn't been implemented I get the exception below: com.oracle.graal.graph.GraalInternalError: java.lang.ClassCastException: com.oracle.graal.api.code.StackSlot cannot be cast to com.oracle.graal.api.code.RegisterValue at lir instruction: xmm2|d = DADD (x: stack:240|d, ~y: stack:248|d) at com.oracle.graal.lir.LIR.emitOp(LIR.java:172) at com.oracle.graal.lir.LIR.emitBlock(LIR.java:161) at com.oracle.graal.lir.LIR.emitCode(LIR.java:147) at com.oracle.graal.lir.hsail.HSAILArithmetic.emit(HSAILArithmetic.java:322) at com.oracle.graal.lir.hsail.HSAILArithmetic$Op2Stack.emitCode(HSAILArithmetic.java:75) at com.oracle.graal.lir.hsail.HSAILLIRInstruction.emitCode(HSAILLIRInstruction.java:36) Is there a switch that can be used to tell Graal not to generates nodes like the above, since we don't support them yet? Vasanth From christian.wimmer at oracle.com Wed May 29 13:30:41 2013 From: christian.wimmer at oracle.com (Christian Wimmer) Date: Wed, 29 May 2013 13:30:41 -0700 Subject: disabling arithmetic nodes with memory operands In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8CBE14@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8CBE14@sausexdag06.amd.com> Message-ID: <51A66571.8050607@oracle.com> The AllocatableValue fields of LIR instructions, which reference the operands, are annotated with @Def, @Use, or @Temp. As part of the annotation, you specify the allowed locations. For example, @Use({REG, STACK}) means that the register allocator can use the operand directly from a stack slot. If you change it to @Use({REG}), then the register allocator emits a load into a register first if the operand was spilled. -Christian On 05/29/2013 01:06 PM, Venkatachalam, Vasanth wrote: > Hi, > > For an arithmetic test case involving doubles, Graal is generating a node for a double addition where one of the arguments is a stack slot. > > Unlike x86, HSAIL doesn't support passing a stack slot or memory address as one of the arguments to an addition. > The HSAIL backend I've developed would have to load the value from the stack into a register first and do a register to register addition. Since this hasn't been implemented I get the exception below: > > com.oracle.graal.graph.GraalInternalError: java.lang.ClassCastException: com.oracle.graal.api.code.StackSlot cannot be cast to com.oracle.graal.api.code.RegisterValue > at lir instruction: xmm2|d = DADD (x: stack:240|d, ~y: stack:248|d) > at com.oracle.graal.lir.LIR.emitOp(LIR.java:172) > at com.oracle.graal.lir.LIR.emitBlock(LIR.java:161) > at com.oracle.graal.lir.LIR.emitCode(LIR.java:147) > at com.oracle.graal.lir.hsail.HSAILArithmetic.emit(HSAILArithmetic.java:322) > at com.oracle.graal.lir.hsail.HSAILArithmetic$Op2Stack.emitCode(HSAILArithmetic.java:75) > at com.oracle.graal.lir.hsail.HSAILLIRInstruction.emitCode(HSAILLIRInstruction.java:36) > > > Is there a switch that can be used to tell Graal not to generates nodes like the above, since we don't support them yet? > > Vasanth > > From Gary.Frost at amd.com Thu May 30 11:40:00 2013 From: Gary.Frost at amd.com (Frost, Gary) Date: Thu, 30 May 2013 18:40:00 +0000 Subject: =?Windows-1252?Q?HSA_Foundation_releases_version_0.95_of_the_=91Programme?= =?Windows-1252?Q?rs_Reference_Manual=92_(HSAIL_Spec).?= Message-ID: Yesterday the HSA Foundation released their ?Programmers Reference Manual?. This manual is for developers wishing to write code for upcoming HSA compatible devices, it describes the HSA Intermediate Language (HSAIL) along with its binary form (BRIG) and describes how code is expected to execute on a HSA enabled devices. In many ways we can think of HSAIL as we do Java bytecode. It is a common intermediate form that can be optimized at runtime to execute across a variety of future heterogeneous platforms. HSAIL will greatly simplify the development of software taking advantage of both sequential and parallel compute solutions. I predict that this will prove to be a big deal for both Graal and Sumatra. Sumatra developers working inside AMD already have a prototype that can intercept the dispatch of specific Lambda/Stream API?s, generate HSAIL(via an HSAIL-enabled GRAAL backend) and execute this code. We have executed code for several applications and test cases on simulators as well as on early access HSA compatible hardware. We have been waiting for the HSAIL spec to be released. Now that the spec is out, we will make contributions to both the GRAAL and Sumatra mercurial repositories within the next 2 weeks. Gary Links: HSA announcement http://hsafoundation.com/hsa-foundation-has-just-released-version-0-95-of-the-programmers-reference-manual-which-we-affectionately-refer-to-as-the-hsail-spec/ Spec/manual https://hsafoundation.box.com/s/m6mrsjv8b7r50kqeyyal From Vasanth.Venkatachalam at amd.com Thu May 30 15:01:21 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 30 May 2013 22:01:21 +0000 Subject: HSAIL backend support for Graal Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8CC32D@sausexdag06.amd.com> I have developed an HSAIL backend for Graal, which supports arithmetic instructions, loads and stores, move operations, control flow instructions and some math library functions. Despite being work in progress, we already have several test cases for which Graal generates correct HSAIL code that produces the right answer in an HSAIL simulator. We plan to submit a webrev next week that provides: 1) HSAIL code generation support for Graal. 2) A unit testing framework that includes several test cases known to work with the HSAIL backend. Over the next few days, we will give examples that illustrate how this new backend generates HSAIL code for simple Java programs. Vasanth From thomas.wuerthinger at oracle.com Fri May 31 06:07:26 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 31 May 2013 15:07:26 +0200 Subject: HSAIL backend support for Graal In-Reply-To: <5DD1503F815BD14889DC81D28643E3A73D8CC32D@sausexdag06.amd.com> References: <5DD1503F815BD14889DC81D28643E3A73D8CC32D@sausexdag06.amd.com> Message-ID: <34E164DE-C5D7-4CBF-990D-77208D05CF30@oracle.com> That is great news! Thanks for your efforts - we are looking forward to integrating the HSAIL backend into the Graal source code base. As an important follow-up step, we will have to integrate HSAIL in our gate and performance testing system. Can we use an HSAIL emulator for this or at what point in time is it possible to get hardware executing HSAIL? - thomas On May 31, 2013, at 12:01 AM, "Venkatachalam, Vasanth" wrote: > I have developed an HSAIL backend for Graal, which supports arithmetic instructions, loads and stores, move operations, control flow instructions and some math library functions. Despite being work in progress, we already have several test cases for which Graal generates correct HSAIL code that produces the right answer in an HSAIL simulator. > > We plan to submit a webrev next week that provides: > > 1) HSAIL code generation support for Graal. > 2) A unit testing framework that includes several test cases known to work with the HSAIL backend. > > Over the next few days, we will give examples that illustrate how this new backend generates HSAIL code for simple Java programs. > > Vasanth > > From thomas.wuerthinger at oracle.com Fri May 31 06:16:42 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 31 May 2013 15:16:42 +0200 Subject: =?windows-1252?Q?Re=3A_HSA_Foundation_releases_version_0=2E95_of?= =?windows-1252?Q?_the_=91Programmers_Reference_Manual=92_=28HSAI?= =?windows-1252?Q?L_Spec=29=2E?= In-Reply-To: References: Message-ID: Thanks for your efforts related to Graal and HSAIL! We absolutely share the believe that the support for a variety of heterogeneous platforms will prove a big deal for Graal. We are looking forward to integrate the HSAIL contributions into the Graal OpenJDK mercurial repositories. - thomas On May 30, 2013, at 8:40 PM, "Frost, Gary" wrote: > Yesterday the HSA Foundation released their ?Programmers Reference Manual?. This manual is for developers wishing to write code for upcoming HSA compatible devices, it describes the HSA Intermediate Language (HSAIL) along with its binary form (BRIG) and describes how code is expected to execute on a HSA enabled devices. > > In many ways we can think of HSAIL as we do Java bytecode. It is a common intermediate form that can be optimized at runtime to execute across a variety of future heterogeneous platforms. HSAIL will greatly simplify the development of software taking advantage of both sequential and parallel compute solutions. > > I predict that this will prove to be a big deal for both Graal and Sumatra. > > Sumatra developers working inside AMD already have a prototype that can intercept the dispatch of specific Lambda/Stream API?s, generate HSAIL(via an HSAIL-enabled GRAAL backend) and execute this code. We have executed code for several applications and test cases on simulators as well as on early access HSA compatible hardware. > > We have been waiting for the HSAIL spec to be released. Now that the spec is out, we will make contributions to both the GRAAL and Sumatra mercurial repositories within the next 2 weeks. > > Gary > > Links: > HSA announcement > > http://hsafoundation.com/hsa-foundation-has-just-released-version-0-95-of-the-programmers-reference-manual-which-we-affectionately-refer-to-as-the-hsail-spec/ > > > > Spec/manual > > https://hsafoundation.box.com/s/m6mrsjv8b7r50kqeyyal > From Gary.Frost at amd.com Fri May 31 06:28:07 2013 From: Gary.Frost at amd.com (Frost, Gary) Date: Fri, 31 May 2013 13:28:07 +0000 Subject: HSAIL backend support for Graal In-Reply-To: <34E164DE-C5D7-4CBF-990D-77208D05CF30@oracle.com> Message-ID: Thomas, We do indeed have an emulator, and the Graal/Sumatra test harness that we have been using relies on validating results between Java execution, this emulator and of course we also have early access to hardware to test against. We are looking at open sourcing our emulator so we can make it available for Sumatra/Graal users, hopefully this won't take too long. We also are talking with Donald Smith to see if we can temporarily make a binary implementation available (without source) without hitting license issues. We will keep you updated. Gary On 5/31/13 8:07 AM, "Thomas Wuerthinger" wrote: >That is great news! Thanks for your efforts - we are looking forward to >integrating the HSAIL backend into the Graal source code base. As an >important follow-up step, we will have to integrate HSAIL in our gate and >performance testing system. Can we use an HSAIL emulator for this or at >what point in time is it possible to get hardware executing HSAIL? > >- thomas > >On May 31, 2013, at 12:01 AM, "Venkatachalam, Vasanth" > wrote: > >> I have developed an HSAIL backend for Graal, which supports arithmetic >>instructions, loads and stores, move operations, control flow >>instructions and some math library functions. Despite being work in >>progress, we already have several test cases for which Graal generates >>correct HSAIL code that produces the right answer in an HSAIL simulator. >> >> We plan to submit a webrev next week that provides: >> >> 1) HSAIL code generation support for Graal. >> 2) A unit testing framework that includes several test cases known to >>work with the HSAIL backend. >> >> Over the next few days, we will give examples that illustrate how this >>new backend generates HSAIL code for simple Java programs. >> >> Vasanth >> >> > > From thomas.wuerthinger at oracle.com Fri May 31 06:36:44 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 31 May 2013 15:36:44 +0200 Subject: HSAIL backend support for Graal In-Reply-To: References: Message-ID: OK, sounds good. A binary version of the emulator would be good enough. The main use would be to ensure our regular commits do not break anything related to HSAIL. - thomas On May 31, 2013, at 3:28 PM, "Frost, Gary" wrote: > Thomas, > > We do indeed have an emulator, and the Graal/Sumatra test harness that we > have been using relies on validating results between Java execution, this > emulator and of course we also have early access to hardware to test > against. > > We are looking at open sourcing our emulator so we can make it available > for Sumatra/Graal users, hopefully this won't take too long. We also are > talking with Donald Smith to see if we can temporarily make a binary > implementation available (without source) without hitting license issues. > We will keep you updated. > > Gary > > On 5/31/13 8:07 AM, "Thomas Wuerthinger" > wrote: > >> That is great news! Thanks for your efforts - we are looking forward to >> integrating the HSAIL backend into the Graal source code base. As an >> important follow-up step, we will have to integrate HSAIL in our gate and >> performance testing system. Can we use an HSAIL emulator for this or at >> what point in time is it possible to get hardware executing HSAIL? >> >> - thomas >> >> On May 31, 2013, at 12:01 AM, "Venkatachalam, Vasanth" >> wrote: >> >>> I have developed an HSAIL backend for Graal, which supports arithmetic >>> instructions, loads and stores, move operations, control flow >>> instructions and some math library functions. Despite being work in >>> progress, we already have several test cases for which Graal generates >>> correct HSAIL code that produces the right answer in an HSAIL simulator. >>> >>> We plan to submit a webrev next week that provides: >>> >>> 1) HSAIL code generation support for Graal. >>> 2) A unit testing framework that includes several test cases known to >>> work with the HSAIL backend. >>> >>> Over the next few days, we will give examples that illustrate how this >>> new backend generates HSAIL code for simple Java programs. >>> >>> Vasanth >>> >>> >> >> > > From bharadwaj.yadavalli at oracle.com Fri May 31 07:51:03 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 31 May 2013 07:51:03 -0700 (PDT) Subject: HSAIL backend support for Graal In-Reply-To: References: Message-ID: <51A8B8D7.9060900@oracle.com> On 5/31/2013 9:28 AM, Frost, Gary wrote: > We are looking at open sourcing our emulator so we can make it available > for Sumatra/Graal users, hopefully this won't take too long. We also are > talking with Donald Smith to see if we can temporarily make a binary > implementation available (without source) without hitting license issues. > We will keep you updated. I am also very much interested in the (binary or source) emulator. Please post to Sumatra/Graal mailing list once it is available. Thanks, Bharadwaj From Vasanth.Venkatachalam at amd.com Fri May 31 14:02:28 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Fri, 31 May 2013 21:02:28 +0000 Subject: possible bug in mx/projects handling Message-ID: <5DD1503F815BD14889DC81D28643E3A73D8CC90C@sausexdag06.amd.com> Hi, We have a project com.amd.sumatra which requires java 1.8 compliance to build. We've added lines in mx/project to specify that the project shouldn't be built when building with a 1.7 JDK: distribution at GRAAL@path=graal.jar distribution at GRAAL@dependencies=com.oracle.graal.hotspot.amd64,com.oracle.graal.hotspot.sparc,com.oracle.graal.hotspot,com.amd.sumatra # com.amd.sumatra project at com.amd.sumatra@subDir=graal project at com.amd.sumatra@sourceDirs=src project at com.amd.sumatra@dependencies=com.oracle.graal.hotspot,com.oracle.graal.hotspot.amd64,com.oracle.graal.hsail,com.oracle.graal.compiler.hsail,com.amd.okra project at com.amd.sumatra@checkstyle=com.oracle.graal.graph project at com.amd.sumatra@javaCompliance=1.8 When I do an mx build, I see the lines Excluding com.amd.sumatra fro build (Java compliance level 1.8 required) But then Graal goes ahead and tries to build the package. This appears to be a bug. Can someone look into this? Vasanth